The Chrome UX Report, usually shortened to CrUX, is where Google’s view of your page experience comes from. When PageSpeed Insights shows a field data panel, or Search Console groups URLs by Core Web Vitals status, the numbers trace back to this dataset. Google’s own documentation on the Chrome UX Report describes it as “a dataset that reflects how real-world Chrome users experience popular destinations on the web.” The word that matters in that sentence is popular. CrUX is not a monitoring tool you switch on; it is a sample you either appear in or you do not.
This post covers what the chrome ux report measures, who gets included, the ways to access it and how to read it without over-reading it.
What the Chrome UX Report measures
CrUX covers the user-centric Core Web Vitals metrics: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness and Cumulative Layout Shift for visual stability. The data is collected, in Google’s words, “from real browsers around the world, based on certain browser options which determine user eligibility.” Nobody scripted a test. These are visits from people on their own phones and laptops, on their own connections.
That is the whole point of field data, and the reason it outranks anything you measure yourself when it comes to the Core Web Vitals assessment. PageSpeed Insights, which surfaces CrUX data, describes its field figures as covering “the previous 28-day collection period” and assesses them at the “75th percentile”. A page passes “if the 75th percentiles of all three metrics are Good”. So the number you see is not an average. It is the experience of the visit three quarters of the way down the distribution, which is usually someone on a slower device than yours.
If you want the background on why your own tests disagree with this, our post on lab data vs field data walks through the differences in device, network, cache and behaviour that pull the two apart.
Who gets included, and who does not
Eligibility is the part most people miss. Google states that sites must be “publicly discoverable” and have “a large enough number of visitors in order to create a statistically significant dataset.” Both conditions are filters, and the second one removes a lot of the web.
In practice that means a new site, a small niche site or a deep page with modest traffic may have no URL-level data at all. You might see an origin-level figure that blends every page on the domain, or nothing. Neither is a penalty. It simply means the sample is too thin for Google to publish a number it trusts.
There is a second filter hidden in that eligibility wording. Only Chrome users whose browser options make them eligible contribute. Visitors on other browsers do not appear, and neither do Chrome users who fall outside those options. If a large share of your audience uses something other than Chrome, CrUX describes a slice of your visitors, not all of them.
Five ways to access CrUX data
The same underlying dataset is published through several doors. Google lists BigQuery, the CrUX API, the CrUX History API, PageSpeed Insights and the CrUX Vis dashboard. Which one you use depends on whether you want a quick look, a trend or a bulk analysis.
| Access method | Best for | Effort |
|---|---|---|
| PageSpeed Insights | A quick look at one URL or origin, next to a Lighthouse lab run | None: paste a URL |
| CrUX Vis | Seeing how an origin’s metrics have moved over time, visually | Low |
| CrUX API | Pulling current figures for many URLs or origins into your own reports | Moderate: needs an API key and a script |
| CrUX History API | Tracking trends programmatically, for example before and after a release | Moderate |
| BigQuery | Large-scale analysis across many origins with SQL | High: query costs and SQL knowledge |
For most site owners, PageSpeed Insights covers the daily question and the history view covers the trend question. The API becomes worth the setup when you have more URLs than you are willing to paste one at a time. Our explainer on the PageSpeed Insights score covers how the field panel and the lab score sit on the same page and why they often disagree.
How to read a chrome ux report figure
Start by checking what level the data is at. A URL-level figure describes that page. An origin-level figure describes the whole domain, so a fast homepage and a slow product template are averaged into one picture. If you only have origin data, treat it as a signal that something on the site is slow, then use lab tools to find which templates.
Next, look at which metric is failing. Each of the three tells you a different thing. A poor LCP points towards server response, render-blocking assets or a heavy hero image. A poor CLS points towards elements that load without reserved space. A poor INP is usually JavaScript competing for the main thread, which our guide to Interaction to Next Paint covers in detail.
Finally, remember the window. Because PageSpeed Insights reports field data over the previous 28 days, a fix you shipped yesterday is mixed in with weeks of visits from before it. Field figures move gradually. Checking the day after a deployment and concluding the fix failed is one of the most common misreadings.
What CrUX is good for, and where it stops
The received wisdom is that you should chase a green Lighthouse score. CrUX is the better target, because it is what real people experienced and what the Core Web Vitals assessment uses. If your field data passes and your lab score is mediocre, the users are fine. If your lab score is high and your field data fails, the users are not, and the lab score is the number to stop quoting.
When a report is already showing failures, our walkthrough of a failed Core Web Vitals assessment sets out the order to work in. In short: confirm the failing metric in the field data, reproduce it in the lab, fix the cause, then wait for the 28-day window to roll forward.
The limitation is the one the eligibility rules imply. CrUX tells you nothing about pages without enough eligible Chrome traffic, and it cannot tell you why a metric is poor, only that it is. For a low-traffic site the honest position is that you have no field data, and your lab tests are an estimate of user experience rather than a measurement of it. Plenty of sites rank well with no CrUX data at all. If yours is one of them, collect your own real-user data if you need numbers, and otherwise spend the time on content and links, where the larger gains usually sit. When your traffic grows enough to qualify, the data will appear without you doing anything, and you can start tracking it from there.
Frequently asked questions
What is the Chrome UX Report?
Google describes it as “a dataset that reflects how real-world Chrome users experience popular destinations on the web.” It holds field data for the Core Web Vitals metrics.
Why does my site have no CrUX data?
Sites must be publicly discoverable and have enough visitors to create a statistically significant dataset. Low-traffic pages and new sites often fall below that bar.
How can I access CrUX data?
Through PageSpeed Insights, the CrUX Vis dashboard, the CrUX API, the CrUX History API or BigQuery.
Does CrUX include users of other browsers?
No. It is collected from eligible Chrome users only, so it describes that slice of your audience.
The takeaway Treat CrUX as the scoreboard and lab tools as the diagnosis. If you have no CrUX data, that is a traffic fact, not a problem to fix.
