Reference guide · performance · Published 2026-08-16 · 3 min read
Field data vs lab data for Core Web Vitals
Core Web Vitals field vs lab data: field data comes from real users, lab data comes from a controlled Lighthouse run. Understand both.
- ·Where each data type comes from
- ·What each one can and cannot see
- ·Reading a combined report
Where the two data types come from
Web performance metrics arrive from two very different measurement pipelines, and the distinction is the first thing to get right when diagnosing a Core Web Vitals issue. Lab data is a synthetic measurement taken in a controlled environment, most commonly by Lighthouse running in a throttled emulated device against a single URL. Field data is CrUX data collected from real Chrome users' actual browsing, aggregated over a period. The Core Web Vitals explained article defines the metrics themselves; this one is about the measurement context around them.
The practical summary: lab data tells you what one run on one machine produced, and field data tells you what the real distribution of users experienced.
| Attribute | Lab data (Lighthouse) | Field data (CrUX) |
|---|---|---|
| Source | Emulated run | Real Chrome users |
| Environment | Fixed, controlled | Varied devices and networks |
| Timeframe | Instant snapshot | Aggregated, e.g. over 28 days |
| Coverage | Only the tested URL | Sites with enough traffic |
| Tracks regressions live | No | Yes |
What each one can and cannot see
Lab data excels at reproducing a failure deterministically. Because the environment is fixed, you can change one thing, rerun, and see whether the metric moved. That makes it ideal for the audit procedure where you are isolating a single cause such as a huge hero image or a blocking script. Its weakness is realism: a throttled emulated run does not reflect an actual user on a mid-range device over a slow but real connection, and it uses synthetic throttling rather than a genuinely replayed network.
Field data captures what matters for Google's ranking signals: the true distribution across your visitors. The tradeoff is that field data needs volume. CrUX only reports for URLs with enough traffic, so a low-traffic page may show no field data at all, and it reports in coarse buckets rather than a single instant value. It is the right tool to confirm a fix has shipped to real users and to catch environmental regressions (a new heavy third-party script, a CDN config change) that a single lab run would miss.
Reading a combined report
Use the relationship between the two as the diagnosis. When lab data is bad, the page has a real build problem you can fix in isolation. When lab data is good but field data is poor, the cause is environmental: real devices, real network, third-party scripts, or outside-your-app variability. When both are bad, both levers apply.
A practical workflow is to run Lighthouse for a tight, fast feedback loop, then confirm against field data after launch. The PageSpeed Insights article surfaces both side by side on a single report, which is the fastest way to see lab results immediately and field results when they aggregate. Keep expectations calibrated: a perfect lab run cannot prove field success, and a poor field report is not explained away by a good lab run either. Treat them as two instruments measuring different things and combine them for a complete picture.