Lab data vs field data core web vitals: what each tool measures
Lighthouse is a controlled test: one URL, one simulated device, one throttled network, run at one moment. Search Console and the PageSpeed field section read from the Chrome UX Report, which holds real visits from eligible Chrome users collected over the previous 28 days.
Neither tool is wrong. Lab data answers "can this page be fast?" Field data answers "is it fast for the people who visit it?" Google says its core ranking systems seek to reward good Core Web Vitals, and it recommends that site owners achieve them.
Google's PageSpeed Insights documentation(opens in a new tab) explains the 28-day field window and how it differs from the lab run.
- PageSpeed Insights lab results: one simulated load on a throttled test device.
- Search Console and the PageSpeed field section: the previous 28 days of real Chrome visitors.
- Field data is the one that reflects what your visitors experience.
Why the two disagree
Device mix is the most common cause. Teams test on desktop while most traffic arrives on mobile. Network is the second: real visitors often connect on slower links than the throttle simulates.
Interaction delays are a third cause. INP only appears when real people click and type, and a lab run barely does either. Cache-warm lab runs can also hide the cold-start cost that first-time visitors pay.
Field data also has limits. The Chrome UX Report(opens in a new tab) documents which visitors and pages it includes, so a site whose audience skews to iPhones or Edge sees a partial picture.
| Gap | What to check |
|---|---|
| Device mix | Mobile visitors versus a desktop test |
| Network | Real connections versus the simulated throttle |
| Interaction | INP needs real clicks, which a lab run barely makes |
| Cache | A warm lab run hides the cold visits that first-time users make |
| Who is counted | Only opted-in Chrome users on desktop and Android; iOS Chrome and Edge visits are not in the field data |
Read the Search Console report group by group
Search Console groups similar URLs, so one failing template can mark many pages as poor even when the page you tested is fast. Open the failing group, note its example URLs, and test those URLs in PageSpeed Insights(opens in a new tab).
Do not fixate on the total count of poor URLs. Start with the group that holds the most important pages, and fix the template that the group shares.
When PageSpeed shows no field data
A new or low-traffic page often has no field data. The Chrome UX Report only includes pages that are publicly indexable and have enough visitors, and it does not publish the minimum.
When a URL has too little data, PageSpeed Insights falls back to origin-level data, which covers all pages on the site. In that case the lab run is the only page-level evidence, so use it for debugging and watch the origin numbers for the real result.
CrUX vs Lighthouse: how to work from field data
Start in Search Console(opens in a new tab). Read the 75th-percentile value for each metric, split mobile from desktop, and fix the failing segment first. Then wait out the 28-day window, because the report lags the fix by about a month.
Use the lab for quick iteration between field checkpoints. A lab run tells you whether a change helped. Only the field data tells you whether visitors noticed.
For the usual causes of a failing mobile report on WordPress, read WordPress failing core web vitals mobile.
If scripts are the cause, the third-party script audit shows what to defer.
Open the failing group in Search Console
Test its example URLs in PageSpeed Insights
Find the element behind the failing metric
Fix the shared template, one cause at a time
Wait out the 28-day window, then re-read the field data
Check the failing metric, not the score
A "Poor" status can come from one metric while the others pass. Layout shift, for example, can fail on a page whose largest-paint time is fine. Read the metric that failed, then find the element behind it in the lab test.
If you want the field data read for you, the Core Web Vitals optimization service starts with a field-data diagnostic.
Questions about PageSpeed and Search Console
Is a PageSpeed score of 90 bad for SEO?
Not on its own. A 90 is a lab measure. The Core Web Vitals status uses field data, so check the field section for the URL group that fails.
Why does Search Console flag pages that PageSpeed passes?
Search Console groups similar URLs. Groups can contain a slower template than the page you tested, so test the example URLs in that group.
Which number matters more, lab or field?
Field data. It reports what real visitors experienced over the previous 28 days. Use the lab score to debug a cause, not to judge the result.
Why does PageSpeed show no field data for my page?
Either the page has too few eligible Chrome visits or it is not indexable. PageSpeed Insights then shows origin-level data when it has enough, and the lab run is the only page-level evidence.
How long after a fix does Search Console change?
About a month. The field data covers the previous 28 days, so a fix reaches the report gradually as new visits replace old ones.