User-centric performance metrics

Why performance metrics need to be user-centric

"Fast" is rarely an absolute property of a page. A site that loads quickly on a high-end phone over Wi-Fi can feel sluggish on a mid-range device on cellular. Two pages might finish loading in the same total time, yet one feels quicker because it paints content progressively instead of showing a blank screen. And a page can appear fully loaded while still being unresponsive to taps or clicks. To discuss performance with any precision, you need objective, quantitative metrics — but not just any metric. The numbers you track must correspond to what users actually experience.

The problem with the load event

For years, the standard measure of web performance was the load event. Technically, load is a well-defined point in a page's lifecycle. The catch is that this moment rarely matches anything the user perceives. A page can trigger load almost immediately and then spend several more seconds fetching its actual content, leaving the user staring at a blank screen. By the traditional metric, that page is fast. By any reasonable user experience, it is not.

To improve on this, the Chrome team has worked with the W3C Web Performance Working Group to standardize APIs and metrics that reflect user experience more directly. These metrics are framed around core questions:

Lab measurements vs. field measurements

Performance metrics are generally gathered in one of two environments:

• In the lab: a consistent, controlled simulation of page load.
• In the field: data from real users loading and interacting with the page.

Neither approach alone is sufficient. Lab testing is the only way to evaluate performance before a feature ships, since there are no real users yet to measure. It is the primary defense against performance regressions during development.

But lab results are a proxy at best. Real-world performance varies dramatically with device capability, network conditions, and how users interact with the page. A page that loads personalized content or ads can behave wildly differently for each visitor. The only way to know how a site performs for its actual audience is to measure those real users — a practice called Real User Monitoring (RUM).

Categories of user-perceived performance

Users perceive performance across several distinct dimensions:

• Perceived load speed: how quickly the page can render all of its visual elements.
• Load responsiveness: how quickly the page's JavaScript loads and executes enough to respond quickly to interaction.
• Runtime responsiveness: how quickly the page reacts to user input after load has completed.
• Visual stability: whether elements shift unexpectedly and interfere with what the user is doing.
• Smoothness: whether transitions and animations render at a consistent frame rate and flow naturally.

Given these different dimensions, no single metric can capture the full performance story of a page. A complete picture requires looking at multiple metrics together.

Standard metrics that matter

• First Contentful Paint (FCP): time from the start of page load until any part of the page's content is rendered. (lab, field)
• Largest Contentful Paint (LCP): time until the largest text block or image element is rendered on screen. (lab, field)
• Interaction to Next Paint (INP): measures the latency of every tap, click, or keyboard interaction, selecting the worst (or near-worst) interaction as a representative value of the page's overall responsiveness. (lab, field)
• Total Blocking Time (TBT): the total time between FCP and TTI where the main thread was blocked long enough to prevent input responsiveness. (lab)
• Cumulative Layout Shift (CLS): the cumulative score of unexpected layout shifts from page load until the page's lifecycle state becomes hidden. (lab, field)
• Time to First Byte (TTFB): the time until the network delivers the first byte of a resource in response to a user request. (lab, field)

Some newer metrics fill gaps in what we can measure. In other cases, the best metric for a page is one tailored to that page's specific characteristics.

Custom metrics

The standard metrics give you a general sense of how most sites perform, and they enable comparison against competitors. But a particular site may have unique traits that standard metrics miss. For example, LCP assumes the largest element reflects the page's main content — a premise that doesn't hold for every design.

For those cases, the Web Performance Working Group has standardized lower-level APIs for building your own metrics:

• User Timing API
• Long Tasks API
• Long Animation Frames API
• Element Timing API
• Navigation Timing API
• Resource Timing API
• Server timing

These APIs are the building blocks for measuring the characteristics that matter specifically for your site. The full guide to implementing them is covered in the article on custom metrics.