I once had a client whose PageSpeed score was 98, glowing green in every audit, while their real users complained the site crawled. Another client's Lighthouse was an anxious red while their field data showed they were crushing every threshold. Both were running the same Core Web Vitals and getting opposite answers.
This isn't a software bug. It's lab data and field data describing two different universes, and until you can tell them apart, you'll keep "fixing" problems that aren't real and ignoring the ones that are. This guide is the reconciliation: what each type of data is good for, why they diverge, and which one Google — and your users — actually rank on.
The two universes
Lab data is a controlled experiment. Lighthouse loads your page on a fixed, fast connection, in a clean browser, and measures how it behaves. Same inputs every run, which is the point: because the environment never changes, you can change one thing at a time and reliably observe the effect. Lab data is great for exactly one thing — isolating a specific cause. Is the LCP image too heavy? Is a script blocking render? Is a font delaying first paint? Run Lighthouse, change a variable, run it again. That's the scientific method, and it works.
Field data is the messy truth. It comes from the Chrome User Experience Report (CrUX): the actual experience of millions of real users on their real phones, real networks, moving trains, and congested coffee shops, sampled over a rolling 28-day window. It's a distribution, not a single number. Where Lighthouse gives you a mean or a single score within a controlled environment, field data gives you a percentile curve — the 25th percentile, median, and 75th percentile of every visit. And it is slow to update. A bad deployment today won't show up in CrUX for a week or more.
Here's the metric-level translation, since Core Web Vitals in 2026 are field metrics first and lab scores second:
| Question | Lab data answers | Field data answers |
|---|---|---|
| Is my page fast? | What the page does under ideal, identical conditions | What it does for the slowest quarter of real users |
| What's causing slowness? | Everything — the waterfall, the byte sizes, the blocking time | Very little — it's noisy aggregate data |
| What does Google rank on? | Nothing, directly | Everything, directly |
| What does the business care about? | Sprint targets for engineers | Bounce rate, conversions, revenue |
Why the divergence happens
You're not debugging a bug — you're measuring two realities. Our technical SEO engineering service reconciles them on every audit.
Two people running the same page can get perfectly reasonable opposite answers, for reasons that are baked into the measurement design:
- Different hardware. Lighthouse in 2026 throttles to a mid-range mobile profile by default, but the comparison isn't identical across tools, and the lab runs on a dedicated machine with nothing else going on. Real users run on four-year-old budget Androids with 16 tabs open and a video call in the background.
- Different network. A lab connection is simulated but consistent. Real networks fluctuate — LTE on a subway, public Wi-Fi at a coffee shop, satellite somewhere rural. That variability only shows up in field data.
- Different definitions of "the page." Lab tools measure a single cold load of the URL. Field data blends first-time visitors (cold cache, full payload) with returning visitors (cache warm, far less to download). Google uses field data precisely because it reflects the composite reality you actually face.
- Different aggregation. A single Lighthouse run is one sample. Field data is a 28-day aggregate at the 75th percentile — two minutes of your best user's experience versus the worst load of your worst user's month.
Once you understand those four differences, "why are my scores contradicting each other" stops feeling like a mystery and starts looking like physics.
When they disagree, the field wins — but only for judgment
Here's the ranking truth most people find uncomfortable: Google ranks on field data. It has no choice — it can't run Lighthouse on every page every minute, but it can read real browser telemetry from billions of visits. So when Lighthouse says "fast" and field data says "slow," your users are experiencing slow. Adding caching won't help until you believe the field data, because the field data is describing the experience you're trying to fix.
But here's the part that surprises people in the opposite direction: field data wins the judgment, while lab data wins the diagnosis. The field tells you whether there's a real problem. The lab tells you why. Slapping a CDN in front of a page that's slow because of render-blocking JavaScript is a classic failure mode — the nice field score never arrives because the guess was wrong.
The practical division of labor:
- Confirm with field data first. Check CrUX for your actual pages and your actual user distribution — both movie-percentile buckets and the numeric values. This decides whether a real-user problem exists at all. If the 75th percentile of LCP is 1.8s, you are done. Do not go hunting in the lab.
- Use lab data to find the cause. Once users are confirmed slow, Lighthouse and the waterfall tell you which resource, which render path, and which byte is responsible. This is where lab data is irreplaceable — field data cannot tell you "four scripts block first render."
- Reproduce the field in the lab. If you want lab and field to converge, throttle your lab test to approximate your real field conditions: slow 4G, a mid-range phone profile, third-party scripts left in. A Lighthouse run with everything stripped out is a lab victory with no field meaning — and it's exactly the trap that produces green scores and slow users.
The trap of the bulletproof lab build
It's worth naming the trap explicitly, because it catches teams of all sizes: a page that scores 100 in the lab because every third-party resource was stripped and the connection was a private fiber line proves nothing about the real world, where tag managers, consent banners, and ad networks all load. The lab is only a proxy for the field if the conditions you test resemble the conditions real users get — and if your golden score comes from a page that client-renders its content, no amount of lab polish will help; the fix is render architecture, not caching. Every serious performance team we know keeps a "production-like" lab profile — full third parties, throttled network — and treats that as the number that matters.
The trend is the truth
Field data updates on a rolling window, and that lag corrupts our intuition. Ship a big fix this week and the field data still shows last month's experience for at least seven days, usually more. Two habits save you from acting on stale data:
For a deeper dive, see our guide on site architecture for topical authority.
For a deeper dive, see our guide on understanding crawl budget.
- Don't declare victory for 14–28 days. A fix confirmed in the lab today needs a full field window to show up. Celebrate when the 75th percentile moves, not when Lighthouse ticks green.
- Watch for the trend, not the nightly number. Field data bounces week to week with seasons, traffic mix, and network weather. The direction over three months is the signal; any single night is noise.
What this means for how you report
There's an accountability angle here that matters more than the engineering. Every dashboard you show a stakeholder should state which universe a number came from. A "performance" slide built entirely from Lighthouse scores is describing a laboratory; your clients and bosses assume it's describing their customers. That mismatch is how you end up with confidently wrong decisions about budget and priorities. The honest reporting habit is to lead with field data for the "are we there" answer, and use lab data purely for the "why not" answer. If conversion reporting is part of your cadence, this distinction also tells you which metric is worth tying to revenue, since it's the field experience — not the lab score — that drives bounce and order rates.
The practical habit
Treat the two as a pair, never as competitors. Field data tells you the real user experience and what Google measures. Lab data tells you the mechanism behind it. You need both, in that order: confirm the problem in reality, then diagnose it in the lab. If you'd like the full detail on all three metrics and the exact thresholds to aim for, our Core Web Vitals guide walks through LCP, INP, and CLS end to end.
The clients who get fast are the ones who stop trusting a single green score and start asking which of the two universes is telling the truth about their users. Usually — annoyingly often — it's the messy one. And because a page that's genuinely fast is also the page Googlebot crawls deeper and indexes sooner, getting the diagnosis right has a compounding payoff: speed fixes your experience, your rankings, and your indexation in one go.
If your scores tell two different stories and you're not sure which to trust, our teardown reconciles them — we pull your real-user data, isolate what's actually driving it in the lab, and tell you which fix actually matters. book a free website teardown and we'll cut through the contradiction.