What Is the Difference Between Lab Data and Field Data?
Almost every argument about conflicting performance numbers dissolves once this distinction is clear. The two data sources are not competing measurements of the same thing. They answer different questions, and expecting them to agree is the error.
What exactly is lab data?
A single page load performed by a tool such as Lighthouse or WebPageTest, on defined hardware with throttled CPU and network. Because the environment is fixed, results are reproducible and every change is attributable. Nothing about it reflects your actual audience.
Its strength is the controlled variable. If you change one thing and the lab number moves, that change caused it. Field data cannot give you that, because too many other factors vary between real sessions to isolate a single cause.
What exactly is field data?
Real User Monitoring collected from Chrome users who opted into reporting, aggregated in the Chrome User Experience Report over a rolling 28-day window and reported at the 75th percentile. It reflects genuine devices, networks, cache states and user behaviour across your whole audience.
Its weakness is latency and attribution. A fix takes about a month to be fully reflected, and when a number moves you often cannot tell whether your change caused it or your traffic mix shifted. A campaign bringing older devices can worsen field data with no code change at all.
Why do they disagree so often?
Lab runs use a fixed simulated device that may be faster or slower than your median visitor, load with an empty cache, skip consent banners and personalised content, and never scroll. Field data includes all of that plus the slowest quarter of your audience, which sets the reported percentile.
Cache state alone explains many discrepancies. A lab run always measures a cold load, while a large share of real visits are repeat visitors with warm caches. Depending on your traffic, this can make field data substantially better than lab, or worse if your cache headers are poor.
Which should you act on?
Both, in sequence. Field data tells you whether a problem exists and which metric fails. Lab data tells you what is causing it and confirms a fix works before deployment. Then field data over the following month tells you whether the fix mattered for real users.
Skipping either step causes predictable failures. Working only from lab data produces optimisation of pages nobody has trouble with. Working only from field data leaves you changing things without knowing which change helped, because the feedback loop is a month long.
Key takeaways
- Lab data is a reproducible synthetic run; field data is real users over 28 days.
- Only field data feeds the Core Web Vitals assessment Google uses.
- Lab isolates cause; field measures effect but cannot attribute it cleanly.
- Cold lab caches versus warm real caches explain many disagreements.
- Diagnose in lab, deploy, then confirm in field over the following month.
Frequently asked questions
- Why does my site have no field data?
- The Chrome User Experience Report requires a minimum volume of qualifying visits before it reports a URL or origin. Low-traffic sites often have none, and PageSpeed Insights then shows only lab results. In that case lab data is all you have, and should be interpreted cautiously.
- Can you collect your own field data?
- Yes. The web-vitals JavaScript library reports LCP, INP and CLS from your own visitors, which gives you faster feedback than the 28-day CrUX window and covers browsers CrUX excludes. It is the standard approach for sites that need to iterate quickly.
- Does CrUX include browsers other than Chrome?
- No. It collects only from Chrome users who have opted into reporting, so Safari and Firefox traffic is absent entirely. On sites with heavy iOS traffic this means the official assessment describes a minority of actual visitors, which is worth remembering when interpreting it.
- How quickly does field data respond to a fix?
- Improvement appears gradually as the 28-day window advances, with partial movement visible after a week or two and full reflection after about a month. Expecting an immediate change and concluding the fix failed is a common and avoidable mistake.
Web Performance, BigBalli. We track Core Web Vitals definitions and thresholds as Google revises them, cross-checked against web.dev and Chrome developer documentation.