Two tools can report different Core Web Vitals scores for the same page. Understanding the difference between field and lab data explains why — and tells you which to trust.
A common source of confusion in performance work is that Lighthouse and Google Search Console sometimes report different Core Web Vitals scores for the same page. One says the page is fast; the other says it is slow. Both are right. They measure different things, and understanding the difference between field data and lab data is the key to interpreting either one correctly.
Field data: what real users experience
Field data is collected from real Chrome users through the Chrome User Experience Report. When a visitor loads your page, the browser measures the actual LCP, INP, and CLS they experienced and reports it anonymously. Aggregated across thousands of visits, this produces a picture of how the page performs in the real world: on real devices, real networks, with real third-party scripts and extensions running. Google uses this field data for the Core Web Vitals ranking signal, surfaced in Search Console and the CrUX dashboard.
Field data reflects reality, but it is slow to update and coarse. It is reported as the 75th percentile across a 28-day window, so a fix you ship today may not show up in the numbers for weeks. It also requires enough traffic to populate — a low-traffic page may have no field data at all.
Lab data: what a controlled test shows
Lab data is measured in a simulated environment. Lighthouse loads the page on a simulated device and network (typically a throttled mobile connection), runs a single controlled visit, and reports the metrics. Because the conditions are fixed, lab data is reproducible: run it twice on an unchanged page and you get the same numbers. It is available instantly, on any page, regardless of traffic.
The trade-off is that lab data is one visit under one set of conditions. It does not capture the variability of real users — slow devices, congested networks, third-party scripts that loaded differently. A page that scores well in the lab can still perform poorly for real users if, for example, a slow ad script loads on most visits but not in the lab.
Why they disagree
When field and lab data disagree, the field data is usually the more important signal, because it reflects what real users experience and what Google uses for ranking. A disagreement usually points to a condition the lab does not simulate: a third-party script that varies, a slow server under real load, a cache that is warm in the lab but cold for real users, or a device profile slower than the lab’s simulation. Investigate the gap rather than trusting one number.
Tools for each
- Field data: Google Search Console (Core Web Vitals report), the CrUX dashboard, PageSpeed Insights (field section).
- Lab data: Lighthouse (in Chrome DevTools or PageSpeed Insights lab section), WebPageTest.
- Real-time field measurement on your own page: the web-vitals JavaScript library, which lets you collect metrics from your actual visitors.
- Synthetic monitoring: tools that run lab tests on a schedule to catch regressions over time.
A practical workflow
Start with Search Console’s Core Web Vitals report to see which pages have poor field data — those are the pages that matter for ranking. For each flagged page, run Lighthouse to get lab data and specific recommendations. Fix the issues Lighthouse identifies, then re-measure with both lab and field. Use the web-vitals library to confirm the fix with real users if you want faster feedback than the 28-day CrUX window.
Which to trust
For ranking, trust field data — it is what Google uses. For diagnosis and iteration, use lab data — it is fast, reproducible, and gives actionable advice. For ground truth on a specific change, instrument your own page with the web-vitals library and watch the metrics your real users generate. The three approaches answer different questions, and a mature performance process uses all three.
Core Web Vitals are measurable, which is what makes them actionable. Pick the right tool for the question you are asking, interpret the numbers in context, and the gap between “the page feels slow” and “here is the number to fix” closes quickly.