Most performance arguments die on a false premise: that a page has a Core Web Vitals score. It doesn’t. It has two, they measure different things, and the field vs lab data distinction decides which one Google uses to rank you and which one is only useful for debugging. Get the two confused — as most teams do when they screenshot a green Lighthouse run and declare victory — and you optimize the number that doesn’t count while the number that does quietly stays red. This guide is about knowing which is which, why they disagree, and what to do when they do.
The Core Confusion Nobody Names
Here is the whole problem in one sentence: lab data is a prediction, field data is a measurement. Lab data asks “how fast could this page load under these fixed conditions?” Field data asks “how fast did it load for the actual humans who visited?” Those are different questions, so of course they return different answers. The field vs lab data gap isn’t a bug or a tooling error to be reconciled away — it’s the expected result of measuring a controlled simulation against a messy real world.
Google’s page experience signal is built on the messy real world. That single fact reorganizes every optimization decision you’ll make, and it’s the one most “run Lighthouse and fix the reds” tutorials never mention.
What Field Data Actually Is
Field data — also called Real User Monitoring, or RUM — is collected from real people using real devices on real networks as they browse your live site. Google’s public source for it is the Chrome User Experience Report (CrUX), which aggregates anonymized metrics from opted-in Chrome users over a rolling 28-day window. It powers the field section of PageSpeed Insights, the Core Web Vitals report in Search Console, and the CrUX API and dashboards.
Two properties matter more than any other. First, field data is a distribution, not a single number — some users saw a 1.2-second LCP, some saw 6 seconds, and CrUX reports the 75th percentile: the experience at or below which 75% of visits fell. Second, it’s cumulative and lagging. A fix you shipped today won’t fully clear the 28-day window for four weeks, because the slow “before” visits stay in the average until they age out.
What Lab Data Actually Is
Lab data comes from loading your page in a controlled environment with fixed, predefined settings — a specific simulated device, a throttled network, a cold cache — and measuring a single synthetic load. Lighthouse is the canonical engine; it drives the “Diagnose performance issues” panel in PageSpeed Insights, the Lighthouse tab in Chrome DevTools, web.dev/measure, and most CI performance checks.
Its strength is exactly its weakness. Because every variable is pinned, lab runs are reproducible — run it ten times and you get roughly the same score, which is what lets you isolate a single change and prove it helped. But that same controlled environment is a fiction. No real user loads your page on precisely Lighthouse’s simulated mid-tier phone over its exact throttled connection. Lab data tells you what one hypothetical device experiences; it can’t tell you what your audience’s blend of iPhones, budget Androids, fast Wi-Fi, and patchy 4G actually experiences.
Which One Google Ranks You On
The page experience ranking signal uses field data, full stop. Google assesses Core Web Vitals from CrUX — real-user, 75th-percentile, 28-day data — not from your Lighthouse score. This is the single most important takeaway of the entire field vs lab data debate, and it inverts how most teams work.
It means a perfect 100 in Lighthouse earns you nothing directly if real users still suffer. It means lab data is a diagnostic instrument, not a scorecard — you use it to find and fix causes, then you wait for field data to confirm the fix landed with real users. Treating Lighthouse as the finish line is the most common way capable teams waste a quarter of engineering effort on a number Google never reads.
The INP Problem: Why Lab Can’t Measure Interactivity
Since March 2024, INP (Interaction to Next Paint) replaced FID as a Core Web Vital, joining LCP and CLS. The “good” thresholds at the 75th percentile are: LCP ≤ 2.5s, CLS ≤ 0.1, INP ≤ 200ms. INP is where the field-and-lab distinction stops being philosophical and becomes a hard technical limit.
INP measures the latency of real interactions — clicks, taps, key presses — across the whole page lifecycle. You cannot measure that in a lab, because lab tests don’t know when or how a user will interact. There’s no click to time. So Lighthouse reports Total Blocking Time (TBT) as a load-time proxy: how long the main thread was blocked while the page loaded. TBT is genuinely useful, but it is not INP. A page can post a near-perfect TBT and still return a poor INP, because users often interact after load — with a menu, a filter, an accordion — and that interaction fires event handlers TBT never saw. If you only ever check the lab, INP is a metric you are structurally blind to.
Why Your Two Scores Disagree
When field and lab diverge — and they almost always do — the gap is information, not noise. The usual causes:
- Device and network mix. Lighthouse simulates one throttled profile; your real users span a spread. If your audience skews toward fast devices and connections, field will look better than lab. If it skews toward budget phones on mobile data, field looks worse.
- Caching and repeat visits. Lab runs cold every time; many real visits are warm, with fonts, scripts, and images already cached. Repeat visitors post faster LCPs that lab never sees.
- Real interaction patterns. The INP-vs-TBT gap above: field captures what users actually clicked; lab guesses from load-time blocking.
- Geography and CDN. Real users hit edge nodes at varying distances; lab measures from one location.
- The 28-day lag. If you shipped a fix ten days ago, field is still averaging in the slow old experience while lab already shows the improvement.
Read the direction of the gap and it tells you where to look. Lab far better than field usually means real devices are slower than your simulation assumes. Field better than lab often means caching and a favorable audience are saving you — which is fragile if your traffic mix shifts.
The 75th-Percentile Trap
Teams routinely optimize for the median user and wonder why their CrUX numbers stay amber. Google grades at the 75th percentile deliberately: it wants a page to be good for the large majority, not just the typical visitor. Your median (p50) experience can be comfortably green while your p75 is failing, because the slowest quarter of your traffic — older phones, congested networks, heavy third-party scripts firing for some users and not others — drags the reported figure past the threshold.
The practical rule: never celebrate a median. Look at the distribution. A metric where p50 is great but p75 fails is a signal that a specific slice of your audience is having a materially worse experience, and that slice is exactly what you need to profile and fix.
The “No Data” Problem You’ll Eventually Hit
CrUX only reports a URL once it has enough samples to be statistically meaningful. Low-traffic pages — a new post, a deep long-tail landing page — often show no field data at all. PageSpeed Insights falls back to origin-level CrUX (your whole domain’s aggregate) when page-level data is missing, which is directional but can hide a specific slow page inside a fast site’s average.
This is the honest limit of field data: it’s authoritative but only where you have traffic. For pages CrUX can’t see yet, lab data is your only early-warning system — you fix what Lighthouse flags on the assumption that real users will experience the same causes once traffic arrives. Field for what’s live and popular; lab for what’s new or thin. You need both instruments, used for what each is good at.
A Decision Rule for Field vs Lab Data
Stop asking which is “right” and use each for its job:
- Use field data to decide what’s broken and whether a fix worked. It’s the ground truth Google ranks on. If CrUX is green at p75, you’re done, regardless of what lab says.
- Use lab data to find why and to iterate fast. Its reproducibility lets you test one change at a time without waiting 28 days. It’s your debugger, not your grade.
- When they conflict, field wins for the verdict, lab wins for the investigation. A green lab and red field means real users are hurting — trust the field and go dig with the lab.
- For no-data pages, lab is your proxy until enough traffic populates CrUX.
Turning Two Scores Into One Workflow
The operational challenge isn’t understanding field vs lab data — it’s watching it continuously across every page instead of hand-checking PageSpeed Insights one URL at a time. That manual approach is how a regression on a template quietly fails p75 across a hundred pages before anyone notices in Search Console a month later.
This is where continuous monitoring earns its keep. SEO Rocket’s real-crawler site audit surfaces Core Web Vitals flags across your site automatically alongside the crawl issues that often cause them — render-blocking resources, oversized images, redirect chains inflating load — with the underlying fix explained rather than just a red badge. It’s built on a playbook proven across 1,000,000+ ranking pages, and it’s designed as the always-on layer: it won’t replace a deep synthetic-testing rig or field RUM instrumentation for a large enterprise app, but it catches the CWV and technical regressions that matter for the vast majority of sites without a manual audit ritual. Pair that continuous audit with rank tracking on the same SEO Rocket client dashboard and you can see whether a genuine field-data improvement actually moved positions — closing the loop from cause to metric to ranking for roughly $50/month, with a free tier to start.
Frequently Asked Questions
Does Google use lab data or field data for ranking?
Field data. The Core Web Vitals ranking signal is assessed from the Chrome User Experience Report — real Chrome users, measured at the 75th percentile over a rolling 28-day window. Your Lighthouse (lab) score is a diagnostic tool for finding and fixing causes; it does not directly feed the ranking signal, no matter how green it is.
Why is my Lighthouse score good but my Core Web Vitals still failing?
Because they measure different things. Lighthouse runs one simulated load in a controlled lab; CrUX averages real users on real devices at p75. Common causes of the gap: real users are on slower devices or networks than the simulation, your median is fine but the slow quarter fails p75, or INP is poor even though lab TBT looks healthy since users interact after load.
How long does it take for field data to update after a fix?
Up to about 28 days for the change to fully clear CrUX, because field data is a rolling 28-day average and the slow “before” visits stay in the window until they age out. You’ll usually see the trend start to move within a week or two, then stabilize. Lab data reflects a fix immediately, which is exactly why you iterate in the lab and confirm in the field.
