Field data and the Chrome UX Report (CrUX)

When web performance comes up, two ways of measuring exist side by side. One runs in a controlled environment, with a fixed device, a simulated network and a single page load; that is what a lab audit produces. The other records what happens in the browsers of the people who actually reach the site, with their phone, their connection and their cache.

The Chrome UX Report, known by the acronym CrUX, is the public dataset where Google publishes that second measurement. It does not collect just anybody's experience: only Chrome users who have usage statistics reporting enabled, who sync their browser history and who have not set a sync passphrase are included. Chrome on iOS, the web views embedded in Android apps and the remaining Chromium browsers are left out, along with Safari and Firefox.

The page has to meet conditions as well. It must be publicly discoverable, under the same indexability criteria a search engine applies, and it must receive a minimum number of visitors so that the distribution is statistically sound. Google does not publish that threshold.

The value you see does not come from one particular load but from a rolling window of 28 days. Every update recalculates the dataset with the data of the previous 28 days, so an improvement published today takes weeks to show up in full.

Inside that window there is no single number, there is a distribution of experiences. To summarise it, the 75th percentile of visits is taken: the value that 75 % of loads match or beat. The criterion ignores the quarter of visits with the worst experience, so a page can pass while a noticeable minority is still waiting. Measurement is also split between mobile and desktop, and each segment is assessed on its own.

There are several doors into the same data. The Core Web Vitals report in Search Console updates daily, keeps three months of history and groups similar URLs when a single one does not gather enough samples. The public speed analysis tools show the 28-day average of the queried URL and of its domain, without history. The API returns daily data at page and domain level; the history API delivers 40 weekly collection periods. The dataset hosted in BigQuery is monthly, is released on the second Tuesday after the collection period, goes back to 2017 and offers the domain level only.

The question that reaches any SEO team is always the same: why does the lab audit come out green while the Search Console report stays red? Because they measure different things. The lab runs one load from one machine, with a simulated network and an empty cache, and it cannot know when the user will tap. For the interactivity metric, in fact, the lab tool reports a stand-in instead of the real metric.

The field captures what the lab does not see: mid-range phones, real mobile networks, repeat visits with a warm cache, restorations from history that appear instantly, consent banners, ads and personalised content. A high lab score indicates that the page has technical headroom, not that your visitors experience it that way.

For search, the field is what counts. The report Google uses to classify each URL as good or poor is fed by measurements from real users, and the lab audit works as a diagnosis: it lists likely causes and good practices drawn from one predefined load. It helps you find where to act, it does not declare the problem solved.

• Make the decision with the field report and use the lab audit only to pin down the technical cause.
• Add your own measurement on the site if your traffic does not reach the public dataset's threshold or if you need to segment by template, country or device.
• Look at the page level when it exists and fall back to the domain level only when that URL does not gather enough samples.
• Account for the 28-day window when planning, and let at least a full month pass before judging a deployment.
• Review mobile and desktop separately, because the aggregated result hides the segment that fails.
• Look up the specific thresholds of each metric in its own entry before setting an internal target.

• Treating a page as fine because the lab audit shows 100, and never looking at the field report again.
• Reading missing data as a performance problem when it usually means the URL does not have enough visitors or is not indexable.
• Concluding that the public dataset is wrong because one spot check gives a different number, when the difference comes from the 28-day window.
• Optimising the lab tool's overall score instead of the metrics assessed in the field.
• Leaving pages you want to measure on noindex or serving them with a status other than 200, which excludes them under the discoverability criterion.