Web Metrics
Overview
Web Metrics is a new initiative by Google to provide unified guidance for web quality signals that are critical to providing a great web user experience.
Over the years, Google has provided many performance measurement and performance reporting tools. Some developers are very good at using these tools, while others find the large number of tools and metrics overwhelming.
Website owners do not need to be performance experts to understand the quality of experience they provide to users. The Web Metrics Initiative aims to simplify the scene and help websites focus on the most important metrics, namely Core Web Metrics.
Core Web Metrics
Core Web Metrics is a subset of web metrics that apply to all web pages, which every website owner should measure, and these metrics will also appear in all Google tools. Each Core Web Metric represents a different aspect of the user experience that can be realistically measured, and reflects the real experience of key user-centric results.
The metrics that make up the Core Web Metrics will evolve over time. The current metrics for 2020 focus on three aspects of user experience—loading performance, interactivity, and visual stability—and include the following metrics (and their corresponding thresholds):
- Largest Contentful Paint (LCP) : Largest contentful paint, measures loading performance. To provide a good user experience, LCP should occur within 2.5 seconds after the page first starts loading.
- First Input Delay (FID) : First input delay, measures interactivity. To provide a good user experience, the FID of the page should be 100 milliseconds or less.
- Cumulative Layout Shift (CLS) : Cumulative Layout Shift, measures visual stability. To provide a good user experience, a page should have a CLS of 0.1. or less.
To ensure that you are hitting the recommended targets for the majority of your users, a good measurement threshold for each of the above metrics is the 75th percentile of page loads, for both mobile and desktop.
Tools that assess Core Web Metrics compliance should rate a page as passing if it meets the 75th percentile of the recommended targets for all three metrics above.
Info
For more information on the research and methodology behind these recommendations, see: Defining Metric Thresholds for Core Web Metrics
Tools for measuring and reporting Core Web Metrics
Google considers Core Web Metrics to be vital to any web experience. As a result, Google is committed to showing these metrics across all of its popular tools. The following sections detail the tools that support Core Web Metrics.
Real-world tools for Core Web Metrics
The Chrome User Experience Report collects anonymous, real-user measurements for each Core Web Metric.
This data allows site owners to quickly assess performance without manually instrumenting the page, and also powers tools like the PageSpeed Insights page speed measurement tool and the Core Web Metrics report in Search Console.
| LCP | FID | CLS | |
|---|---|---|---|
| Chrome User Experience Report | ✔ | ✔ | ✔ |
| PageSpeed Insights | ✔ | ✔ | ✔ |
| Core Web Metrics Report | ✔ | ✔ | ✔ |
Info
For instructions on using these tools and guidance on choosing the right tool for your use case, see: Getting Started Guide to Measuring Web Metrics
Chrome The data provided by the User Experience Report provides a quick way to assess site performance, but it does not provide detailed telemetry per page view, which is often necessary to accurately diagnose, monitor, and respond quickly to regressions. Therefore, we strongly recommend that sites set up their own real user monitoring.
Measuring Core Web Metrics in JavaScript
Each of the core web metrics can be measured in JavaScript using the standard web APIs.
The easiest way to measure all of the core web metrics is to use the web-vitals JavaScript library, which is a small, production-ready wrapper around the underlying web APIs that measures metrics in a way that matches exactly how each metric is reported in all of the Google tools listed above.
Using the web-vitals library, measuring each metric is as simple as calling a single function (see the documentation for full usage and API details):
import { onCLS, onFID, onLCP } from 'web-vitals'
function sendToAnalytics(metric) {
const body = JSON.stringify(metric)
// Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
;(navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
fetch('/analytics', { body, method: 'POST', keepalive: true })
}
onCLS(sendToAnalytics)
onFID(sendToAnalytics)
onLCP(sendToAnalytics)Once you have configured your site to use the web-vitals library to measure your Core Web Metrics data and send it to analytics, the next step is to aggregate and report on the data to see if your pages meet the recommended thresholds for at least 75% of page visits.
Some analytics tool vendors already have built-in support for Core Web Metrics, but even those that don’t should include basic custom metrics functionality that allows you to measure Core Web Metrics with their tools.
One example is the Web Metrics Report, which enables site owners to measure their Core Web Metrics using Google Analytics. For guidance on measuring Core Web Metrics with other analytics tools, see Best Practices for Field Measurement of Web Metrics.
You can also use the Web Metrics Chrome extension to report on every core web metric without writing any code. The extension uses the web-vitals library to measure each metric and present it to users as they browse the web.
This extension helps you understand the performance of your own site, your competitors’ sites, and the entire web.
| LCP | FID | CLS | |
|---|---|---|---|
| Web Metrics Report | ✔ | ✔ | ✔ |
| Web Metrics Chrome Extension | ✔ | ✔ | ✔ |
Also, developers who prefer to measure these metrics directly through the underlying web APIs can refer to these metrics guides for implementation details:
Info
For more guidance on how to measure these metrics using popular analytics services (or your own internal analytics tools), see: Best Practices for Vital Field Web Metrics
Lab Measurement Tools for Core Web Metrics
While all of the Core Web Metrics are first and foremost field-measured metrics, many of them can also be measured in the lab.
Lab measurements are the best way to test feature performance during development (before it’s released to users) and are the best way to catch performance regressions before they occur.
The following tools can be used to measure core web metrics in a lab environment:
| LCP | FID | CLS | |
|---|---|---|---|
| Chrome Developer Tools | ✔ | ✘ (use TBT instead) | ✔ |
| Lighthouse | ✔ | ✘ (use TBT instead) | ✔ |
Info
Tools like Lighthouse that load pages in a simulated environment without users cannot measure FID (no user input). However, the Total Blocking Time (TBT) metric is both lab-measurable and a good proxy for FID. Performance optimizations that improve TBT in the lab should improve real-world FID (see performance tips below).
While lab measurements are essential to delivering a great experience, they are not a substitute for real-world measurements.
Site performance can vary greatly depending on the user's device capabilities, network conditions, other processes that may be running on the device, and how they interact with the page. In fact, the score for each Core Web Metric is affected by user interaction. Only real-world measurements can accurately capture the full picture.
Tips for Improving Scores
Once you have measured the Core Web Metrics and identified areas for improvement, the next step is optimization. The following guides provide specific suggestions on how to optimize your page for each Core Web Metric:
Other Web Metrics
While the Core Web Metrics are key metrics for understanding and delivering a great user experience, there are other important metrics.
Other web metrics are often used as proxies or supplemental metrics to the core web metrics, helping to capture a broader experience or helping to diagnose specific issues.
For example, the Time to First Byte (TTFB) and First Contentful Paint (FCP) metrics are both important aspects of the loading experience, and can be useful in diagnosing LCP issues (long server response times or rendering blocking resources, respectively).
Similarly, metrics like Total Blocking Time (TBT) and Time to Interactive (TTI) are lab metrics that are critical to capturing and diagnosing potential interactivity issues that impact FID. However, these metrics are not part of the Core Web Metrics because they are not measurable and do not reflect user-centric results.
Evolving Web Metrics
Web Metrics and Core Web Metrics represent the best available signals for developers to measure the quality of the web experience today, but these signals are not perfect and will continue to improve or be supplemented in the future.
Core Web Metrics are relevant to all web pages and are already visible in relevant Google tools. Changes to these metrics will have broad impacts, so developers should assume that the definitions and thresholds of Core Web Metrics are stable and will be updated in advance with a predictable, annual update cadence.
Other Web Metrics are often applicable to specific scenarios or tools and may be more experimental than Core Web Metrics. Therefore, the definitions and thresholds of these metrics may change more frequently.
Changes to all web metrics will be clearly documented in this public changelog.