README.md
1# Chrome Speed Metrics
2
3[TOC]
4
5## Mission
6The Chrome Speed Metrics team aims to quantify users' experience of the web to
7provide Chrome engineers and web developers the metrics, insights, and
8incentives they need to improve it. We aim to:
9
10 * **Quantify** web UX via a high quality set of UX metrics which Chrome devs
11 align on.
12 * **Expose** these metrics consistently to Chrome and Web devs, in the lab and
13 the wild.
14 * **Analyze** these metrics, producing actionable reports driving our UX
15 efforts.
16 * **Own** implementation for these metrics for TBMv2, UMA/UKM, and web perf
17 APIs.
18
19## Goals
20
21### Quantify Users’ Experience of the Web
22Chrome needs a small, consistent set of high quality user experience metrics.
23Chrome Speed Metrics is responsible for authoring reference implementations of
24these metrics implemented using Trace Based Metrics v2 (TBMv2) in
25[tracing/metrics](https://source.chromium.org/chromium/chromium/src/+/master:third_party/catapult/tracing/tracing/metrics/).
26These reference implementations will often require adding C++ instrumentation.
27Some metrics work will also be driven by more focused metrics teams, such as the
28work on Frame Throughput. Chrome Speed Metrics also owns UMA/UKM metrics, and
29speed metrics related Web Perf APIs.
30
31The wider set of folks involved in defining these metrics will include:
32
33 * Area domain experts.
34 * Focused metrics teams.
35 * Devtools folks.
36 * DevX, documenting what these metrics mean for external developers.
37 * Occasional other experts (e.g., UMA folks).
38
39### Expose Consistent Metrics Everywhere
40Chrome Speed Metrics is responsible for ensuring that our core metrics are
41exposed everywhere. This includes collaborating with devtools, lighthouse, etc.
42to make sure our metrics are easy to expose, and are exposed effectively.
43
44### Analyze Chrome Performance, providing data to drive our performance efforts
45Metrics aren’t useful if no one looks at them. Chrome Speed Metrics performs
46detailed analysis on our key metrics and breakdown metrics, providing actionable
47reports on how Chrome performs in the lab and in the wild. These reports are
48used to guide regular decision making processes as part of Chrome’s planning
49cycle, as well as to inspire Chrome engineers with concrete ideas for how to
50improve Chrome’s UX.
51
52### Own Core Metrics
53The Chrome Speed Metrics team will gradually gain ownership of
54[tracing/metrics](https://source.chromium.org/chromium/chromium/src/+/master:third_party/catapult/tracing/tracing/metrics/),
55and will be responsible for the long term code health of this directory. We’re
56also ramping up ownership in the Web Perf API space.
57
58## Contact information
59 * **Email**: speed-metrics-dev@chromium.org
60 * **Tech lead**: sullivan@chromium.org
61 * **File a bug**:
62 * For issues related to web performance APIs, file a bug
63 [here](https://bugs.chromium.org/p/chromium/issues/entry?template=Defect+report+from+developer&components=Blink%3EPerformanceAPIs)
64 * For other kinds of issues, file a bug
65 [here](https://bugs.chromium.org/p/chromium/issues/entry?template=Defect+report+from+developer&components=Speed%3EMetrics)
66
67## APIs we own
68 * [Element Timing](https://github.com/WICG/element-timing)
69 * [Event Timing](https://github.com/WICG/event-timing)
70 * [HR Time](https://github.com/w3c/hr-time/)
71 * [Largest Contentful Paint](https://github.com/WICG/largest-contentful-paint)
72 * [Layout Instability](https://github.com/WICG/layout-instability)
73 * [Longtasks](https://github.com/w3c/longtasks/)
74 * We own some of the implementation details of [Navigation
75 Timing](https://github.com/w3c/navigation-timing/)
76 * We are ramping up on [Page
77 Visibility](https://github.com/w3c/page-visibility/)
78 * [Paint Timing](https://github.com/w3c/paint-timing/)
79 * [Performance Timeline](https://github.com/w3c/performance-timeline)
80 * We own some of the implementation details of [Resource
81 Timing](https://github.com/w3c/resource-timing)
82 * [User Timing](https://github.com/w3c/user-timing)
83
84## Web performance objectives
85 * See our [web performance objectives](webperf_okrs.md).
86
87## Metrics changelog
88We realize it's important to keep developers on the loop regarding important
89changes to our metric definitions. For this reason, we have created a [metrics
90changelog](../speed/metrics_changelog/README.md) which will be updated over time.
91
92## User Docs
93 * [Metrics for web developers](https://web.dev/metrics/).
94 * [Properties of a good metric](../speed/good_toplevel_metrics.md)
95 * [Survey of current
96 metrics](https://docs.google.com/document/d/1Ww487ZskJ-xBmJGwPO-XPz_QcJvw-kSNffm0nPhVpj8/edit)
97
98## Talks
99 * [Lessons learned from performance monitoring in
100 Chrome](https://www.youtube.com/watch?v=ctavZT87syI), by Annie Sullivan.
101 * [Shipping a performance API on
102 Chromium](https://ftp.osuosl.org/pub/fosdem/2020/H.1309/webperf_chromium_development.webm),
103 by Nicolás Peña Moreno.
104 * [Understanding Cumulative Layout
105 Shift](https://www.youtube.com/watch?v=zIJuY-JCjqw), by Annie Sullivan and
106 Steve Kobes.