Chrome UX Report (CrUX) and Core Web Vitals

Chrome UX Report (CrUX) is a public dataset of aggregated, real-user Chrome performance measurements. Frontend engineers use it to understand Core Web Vitals in actual browsing conditions rather than relying only on synthetic lab tests.

CrUX collects performance data from eligible Chrome users who have opted into usage statistics and aggregates it before publication. The data represents real experiences across devices, network conditions, and geographic locations, making it useful for evaluating how a site performs for its actual audience.

For Core Web Vitals, CrUX commonly reports metrics such as Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). These measurements describe loading performance, interaction responsiveness, and visual stability from the user's perspective.

CrUX data is organized around origins and, where available, more detailed dimensions such as URL or form factor. Engineers can access it through tools such as the Chrome UX Report API, BigQuery dataset, or PageSpeed Insights. The available granularity and history depend on the particular interface and dataset.

Because CrUX is field data, it can reveal problems that a controlled local test misses. However, it is aggregated rather than a complete trace of every visitor, and small sites may have insufficient data for some dimensions. Lab tools such as Lighthouse complement CrUX by providing repeatable diagnostic measurements and opportunities to investigate individual pages.

Key points

• CrUX is based on aggregated real-user Chrome measurements.
• It is commonly used to evaluate Core Web Vitals at scale.
• Key Web Vitals include LCP, INP, and CLS.
• Field data reflects varied real-world devices and network conditions.
• Use lab diagnostics alongside CrUX when investigating specific performance causes.

Interview questions

What limitations should you consider when interpreting CrUX data?

CrUX is aggregated data, so it does not provide a complete trace for every individual visit. Availability can also depend on whether enough qualifying data exists for the requested origin, page, or dimension. The dataset should therefore be interpreted as a population-level signal rather than an exhaustive record. Engineers should also consider the time period and segmentation represented by the queried data.

What is the Chrome UX Report, and why would a frontend engineer use it?

CrUX is a dataset containing aggregated performance measurements from real Chrome users. It is useful for seeing how a website performs in production across different users and environments. For Core Web Vitals, it can show whether real experiences meet recommended thresholds. This complements local testing because a developer's machine and network may not represent the site's broader audience.

What are the main Core Web Vitals represented in CrUX?

The current Core Web Vitals include Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. LCP measures loading performance, INP measures responsiveness to user interactions, and CLS measures unexpected visual movement. Together they cover important aspects of loading, interactivity, and visual stability. CrUX can show how these metrics are distributed among real users.

Why might CrUX show poor performance when Lighthouse looks good?

Lighthouse is a lab measurement performed under controlled conditions, while CrUX reflects aggregated experiences from real users. Real users may have slower devices, different network conditions, geographic variation, or different page-entry paths. A local Lighthouse run therefore does not necessarily represent the production population. Comparing the two helps distinguish reproducible page-level problems from issues that emerge primarily in the field.

How would you use CrUX during a performance investigation?

I would first establish whether the production experience is actually poor by examining the relevant CrUX distributions and time period. I would then segment the data where useful, such as by form factor, to identify whether the problem is concentrated in a particular audience. After identifying a likely affected experience, I would use lab tooling, browser performance traces, and application telemetry to diagnose causes. Finally, I would deploy a change and use subsequent field measurements to determine whether real-user performance improved.