Core Web Vitals: Field Data vs Lab Data (CrUX Explained)

If you have ever run PageSpeed Insights twice and seen two different stories on the same page, you have met the central confusion of Core Web Vitals. One number says the page is fine. Another says it is slow. Both are correct, because they are measuring two different things. This guide explains the difference between field data and lab data, why they disagree, what CrUX is, and which number actually decides how Google judges your page.

Field data and lab data in one sentence each

Field data is a record of what really happened to real people who loaded your page in Chrome, collected from a large pool of users over time. Lab data is the result of a single controlled test that a tool runs on demand, on a fixed device and network profile, so the result is clean and repeatable.

Field data is sometimes called real user monitoring, or RUM. Lab data is sometimes called synthetic monitoring. The shorthand worth remembering: field data answers "how is my page actually doing?" and lab data answers "what is wrong with my page and can I reproduce it?"

The comparison at a glance

What CrUX actually is

The Chrome User Experience Report, or CrUX, is Google's public dataset of real-world performance measurements. It is the official source of field data for Core Web Vitals, and it is the data Google uses to assess the page experience of your site for ranking purposes.

The measurements come straight from the Chrome browser, not from a JavaScript tag you install. According to Chrome's published methodology, a user only contributes data if they meet a set of conditions: they have enabled usage statistic reporting, they sync their browsing history, and they have not set a sync passphrase. The data is collected from Chrome on Windows, macOS, ChromeOS, Linux, and Android. Notably, Chrome on iOS, Android WebView, and other Chromium-based browsers are not included.

This matters for one practical reason: CrUX represents a large but specific slice of your Chrome audience, not literally every visit. It is a sample, but a large and statistically grounded one, which is exactly why Google trusts it for ranking.

What CrUX measures

CrUX reports the three Core Web Vitals plus a couple of supporting metrics, aggregated at both the individual URL level and the whole-origin (domain) level:

• Largest Contentful Paint (LCP), your loading measure. See our complete guide to LCP.
• Interaction to Next Paint (INP), your responsiveness measure. See our complete guide to INP.
• Cumulative Layout Shift (CLS), your visual stability measure. See our complete guide to CLS.
• First Contentful Paint and Time to First Byte, which are useful diagnostics but are not Core Web Vitals.

The 28-day rolling window

CrUX does not report yesterday's traffic. Every data point is an aggregate of the previous 28 days, and the window is updated daily. So a measurement you pull today reflects roughly the last four weeks of real visits, all blended together.

This has a consequence that trips people up constantly. When you ship a fix, you will not see the field number jump the next morning. The improvement enters the 28-day pool one day at a time, so the field score moves gradually and only fully reflects your change after the old data has aged out of the window. Patience is part of the process.

The 75th-percentile rule

CrUX does not report an average. It reports the 75th percentile. To assess a metric, line up all the real visits from fastest to slowest and look at the value at the 75 percent mark. In plain terms, three out of four of your visitors had an experience at least this good.

For a page to pass a Core Web Vital, that 75th-percentile value has to land in the "good" range. The thresholds Google uses are:

Why the 75th percentile and not the average or the median? Because an average hides your worst experiences, and the goal is to make sure the large majority of real people have a good time, including those on slower phones and weaker connections. Targeting p75 forces you to care about more than just your fastest visitors.

Why field and lab data disagree

When the two numbers conflict, nothing is broken. They are built to differ. Google's own guidance on web.dev lays out the reasons, and they all come back to one idea: the lab controls for the messiness of the real world, and the field captures it.

• Devices vary. A lab test runs on one simulated device. Your real audience is a spread of flagship phones, budget phones, and desktops.
• Networks vary. Lab tests use a fixed throttling profile. Real visitors are on fast fiber, congested mobile data, and everything in between.
• Caches differ. Lab tests usually load with an empty cache, while many real visitors are returning users with files already cached, and some pages load almost instantly from the back-forward cache.
• User behavior is unpredictable. Metrics like INP and CLS depend on what people do. The lab cannot know when a user will click, or scroll past lazy-loaded content that then shifts. The field captures those real interactions.
• Content and geography differ. Personalized content, logged-in states, A/B tests, and the visitor's physical location all shape real-world results but are flattened in a lab test.

A classic example: a lab test never clicks anything, so it cannot produce a real INP value. It can only estimate responsiveness. The only place a true INP score exists is the field, because INP is a record of actual interactions.

Why you fix in the lab but are judged in the field

Here is the workflow that ties it together. Field data tells you whether a problem exists and how badly it affects real users. But field data is an aggregate over weeks, so it is terrible for debugging. You cannot step through it, you cannot reproduce a single bad load, and you cannot test a fix against it in real time.

That is what the lab is for. Lab data is reproducible by design, so you can isolate a render-blocking script, test a change, and confirm the diagnostic moved, all in minutes. Then you ship the fix, and over the following weeks you watch the field data confirm that real users benefited.

So the rule of thumb is simple. Trust the field data to tell you if and how much. Use the lab to figure out why and to verify your fix before it reaches users. Field data is the verdict. Lab data is the investigation.

The tools, and what each one shows

• PageSpeed Insights is the one tool that shows both at once. The top section pulls field data from CrUX for the URL and origin. The section below it runs a fresh Lighthouse lab test. If field data is missing, the top section simply will not appear.
• Search Console, Core Web Vitals report uses field data only. It groups your URLs into good, needs improvement, and poor based on CrUX, and it is the closest thing to the view Google uses for ranking. There is no lab data here.
• Lighthouse, built into Chrome DevTools, is pure lab data. This is your debugging bench.
• The CrUX Dashboard is a Looker Studio dashboard that visualizes your origin's field data trends month over month, which is ideal for tracking progress after a fix.

An honest note on low-traffic pages

Field data is not guaranteed. CrUX only reports a page or origin once it has gathered enough samples to be statistically confident. Chrome does not publish the exact threshold, but it is real, and it means a brand-new page or a low-traffic page will often have no field data at all.

When that happens, PageSpeed Insights may still show origin-level field data even with no URL-level data, because the whole domain clears the threshold even if one page does not. And if a page has no field data anywhere, lab data is your only signal. That is a perfectly valid place to start. Optimize against the lab, build traffic, and field data will appear once the page is busy enough to measure.

Frequently asked questions