CrUX Vis: how Google shows what your users actually feel

Lab and field data

Lighthouse and WebPageTest measure site speed in controlled conditions: one device, one network, one run. This is convenient during development, but real visitors open the site from slow phones, over mobile networks, with dozens of background tabs. So a site can score well in Lighthouse and still feel slow to users.

Field data about real visits is collected by the Chrome User Experience Report (CrUX) — Google’s report based on anonymized statistics from Chrome users who opted in to send it. CrUX Vis is a free tool for visualizing this data as charts.

What CrUX Vis is

According to Chrome documentation, CrUX Vis is a dashboard that shows weekly historical data from the CrUX History API. Key points:

Not all sites and pages have data: sufficient traffic is required. For an individual URL data is often missing even if the site as a whole has data.

Which metrics it shows

The main ones are the Core Web Vitals:

INP became the primary responsiveness metric on March 12, 2024 and replaced FID. If you see FID in older reports or articles, that metric is outdated.

In addition, CrUX Vis shows auxiliary loading metrics — FCP, TTFB, RTT — as well as ad metrics. Assessment uses the 75th percentile: a metric is considered good if at least 75% of visits are within the threshold.

How to read the charts

1. Enter the site or page URL and choose the device type. Start with phones: most sites have worse metrics there.
2. Look at the trend over 40 weeks, not a single value. A sharp deterioration usually coincides with a deployment: a new analytics script, a widget, or a heavy image on the first screen.
3. Compare the share of “good”, “needs improvement”, and “poor” visits. The average value can look decent while a quarter of visitors get a poor experience.
4. Take into account the delay: data are collected in 28-day periods, so the effect of a fix appears in CrUX only after a few weeks.

What to do about bad metrics

• LCP. Reduce server response time (TTFB), optimize and properly mark the main image (modern format, correct size, do not lazy-load for the first screen), remove blocking CSS and scripts.
• INP. Split long JavaScript tasks, remove heavy event handlers, defer third-party scripts (chats, widgets, analytics), avoid doing unnecessary work on every click.
• CLS. Set dimensions for images and embedded blocks, reserve space for ads and banners, do not insert content above already-rendered content.

Other sources of the same data

For automation — e.g., to compare metrics after each deployment with past weeks — use the CrUX History API: it returns the same data shown in CrUX Vis in JSON format.

Example request (requires an API key from Google Cloud):

curl -s "https://chromeuxreport.googleapis.com/v1/records:queryHistoryRecord?key=API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"origin": "https://example.com", "formFactor": "PHONE", "metrics": ["largest_contentful_paint", "interaction_to_next_paint", "cumulative_layout_shift"]}'

Limitations

• Only Chrome. Visits from Safari and Firefox are not included.
• Requires traffic. A new or small site may have no data at all.
• No real-time data. For instant reaction to regressions you need your own on-site metrics collection (RUM), for example the web-vitals library.

Summary

CrUX Vis is the fastest way to see how a site performs for real users and how that changed over recent months. Lab tests help find the cause, while CrUX field data shows whether users actually felt the result.

Useful links: CrUX Vis documentation, Core Web Vitals.