Core Web Vitals field data vs lab data: which to trust
Lighthouse says your page is fast but Search Console says it is slow. Here is why lab and field data differ, and which one Google uses.
You run Lighthouse and get a score of 98. Then you open Search Console and see a wall of red URLs marked poor. Both tools are working. They are just measuring different things. Knowing which number matters will save you from fixing the wrong problem.
What lab data and field data are
Lab data comes from a test you run. A tool loads your page once, on a fixed device and a fixed network, and records what happened. Lighthouse and the lab section of PageSpeed Insights work this way.
Field data comes from real people. Chrome records performance for users who have opted in to usage statistics, and Google publishes the results in the Chrome User Experience Report, usually called CrUX. It shows how your page actually felt to real visitors on real phones and real connections.
- Lab data is repeatable, instant, and good for debugging.
- Field data is messy, delayed, and the closest thing to the truth.
- Lab data covers one visit. Field data covers many visits across many devices.
Which one Google uses
Google has said that Core Web Vitals in search come from field data. The Core Web Vitals report in Search Console is built on CrUX, not on Lighthouse. So a perfect Lighthouse score does not earn you a pass if your real visitors have a poor experience.
The pass mark is set at the 75th percentile. For a page to count as good, at least three in four visits must meet the threshold. The current thresholds are:
- LCP: 2.5 seconds or less is good, over 4 seconds is poor.
- INP: 200 milliseconds or less is good, over 500 milliseconds is poor.
- CLS: 0.1 or less is good, over 0.25 is poor.
Page experience is one signal among many. Google has been clear that great content can still rank well with weaker vitals, so treat this as a tiebreaker and a user experience goal, not a magic lever.
Why the numbers disagree
When lab and field results clash, one of a few causes is usually behind it.
Your test device is faster than your users
A developer laptop on office wifi is not a mid-range Android phone on a train. Lighthouse applies throttling to mimic a slower device, but it is still a single guess. If a large share of your visitors are on older phones, field numbers will look worse.
Lab tests do not interact with the page
INP measures how fast the page responds to clicks, taps, and key presses across a whole visit. A lab run that only loads the page has no interactions to measure. Lighthouse reports Total Blocking Time as a rough stand-in, but it is only a proxy. A page can have low blocking time and still feel slow when someone opens a menu or a filter.
Real visits include things the lab skips
Field data includes logged-in users, cookie banners, personalized content, ads, and scrolling. CLS in particular often gets worse after the first screen, when late ads or images push content around. A lab test that stops early will miss it.
CrUX is a rolling window
CrUX reports a 28-day rolling period. If you shipped a fix yesterday, the field number will barely move for days or weeks. Lab data will show the improvement right away. This gap is normal and not a sign the fix failed.
How to use both
Treat field data as the scoreboard and lab data as the workbench. Here is a workflow that keeps them in their lanes.
- Open the Core Web Vitals report in Search Console and find the URL groups marked poor or needs improvement.
- Check one sample page from each group in PageSpeed Insights. Read the field section at the top first, then the lab section below it.
- Note which metric fails in the field. Reproduce it in the lab with throttling turned on and the Chrome DevTools performance panel open.
- Fix the cause, then confirm the improvement in the lab straight away.
- Wait for the 28-day window to roll before you judge the result in the field.
When there is no field data
Low-traffic pages often have no CrUX data at all, because there are too few opted-in visits to report. PageSpeed Insights may then fall back to origin-level data, which blends every page on your domain, or show nothing. In that case lab data is all you have for that page. Use it, but keep in mind it describes a test, not your visitors.
If you want your own field numbers, you can collect them with the open-source web-vitals JavaScript library and send them to your analytics. This captures every visit, not just Chrome users who opted in. It takes some setup, but it shows you which pages and devices struggle on a given day, without waiting on the 28-day window.
The takeaway
Stop chasing a Lighthouse score of 100. Start from the Search Console report, find the metric that fails for real users, and use lab tools to reproduce and fix it. Then give the field data a month to prove the fix worked.