Core Web Vitals Field Data vs Lab Data Explained
Why Field Data and Lab Data Differ
Core Web Vitals reporting can look contradictory. Lighthouse may show a green score while Google Search Console still reports poor URLs. That does not mean one tool is broken. It means the tools are measuring different things.
Lab data is a controlled test. Field data is real user experience data. Lab data helps you debug. Field data tells you whether users are actually getting a good experience. Both matter, but they should not be used for the same decision. For the full performance framework, start with our Core Web Vitals pillar guide.
What Field Data Means
Field data comes from real users. It reflects actual devices, browsers, locations, network conditions, CPU speeds, cache states, and user behaviour. In Google's ecosystem, this is commonly surfaced through CrUX, PageSpeed Insights field data, and the Search Console Core Web Vitals report.
Field data answers questions like:
- Are real users passing Core Web Vitals?
- Which URL groups are failing at scale?
- Are mobile users worse affected than desktop users?
- Did the latest release improve real performance?
Field data is the truth you optimise towards. The downside is delay. It can take time for enough new data to accumulate after a fix.
What Lab Data Means
Lab data is generated in a controlled test environment. Lighthouse, Chrome DevTools and WebPageTest are common lab tools. They do not represent every user, but they help you isolate why a page is slow or unstable.
| Data Type | Best For | Limitation |
|---|---|---|
| Field data | Understanding real user experience | Slower to update and less granular |
| Lab data | Debugging causes and testing fixes | May not match real-world users |
| Search Console | Identifying affected URL groups | Grouped and delayed reporting |
| DevTools | Finding exact technical bottlenecks | Single-session diagnostic view |
Use lab data to find and fix causes. Use field data to confirm the fix worked for users.
Why Lighthouse Can Pass While Search Console Fails
This is the most common misunderstanding. A single Lighthouse run may pass because the test device, network, cache state, and page path are favourable. Search Console can still fail because real users have slower devices, weaker connections, different locations, or different interaction patterns.
Common reasons for mismatch include:
- Lighthouse tested desktop, but field data fails on mobile.
- The test used a warm cache, but users arrive cold.
- Real users interact with components Lighthouse does not trigger.
- Slow third-party scripts vary by geography or consent state.
- Search Console groups similar URLs, so one template issue affects many pages.
- Field data uses a rolling collection window, so fixes take time to appear.
The practical takeaway: do not use Lighthouse as the final verdict. Use it as the debugging lens.
How to Use Both Correctly
The best workflow is simple and repeatable.
- Use Search Console to find failing URL groups.
- Choose representative URLs from each group.
- Use PageSpeed Insights to compare field and lab signals.
- Use DevTools or WebPageTest to isolate the technical cause.
- Fix the template or component pattern.
- Deploy and test again in lab tools.
- Wait for field data to update before declaring success.
This avoids the usual trap: fixing one URL in a lab test while the real failing pattern remains live across the template.
Metric-Specific Notes
Each metric behaves differently in field and lab tools.
- LCP: Lab tools can usually identify the LCP element clearly, but field LCP may vary by device and viewport.
- INP: Field data is especially important because real interactions are difficult to simulate fully in one lab run.
- CLS: Lab tools can show load shifts, but field data can reveal shifts caused by user interactions, ads, consent banners, and late widgets.
- TTFB: Lab tests are useful, but regional field patterns and bot logs often reveal server problems more clearly.