Main area
Agency
technisches-seo

Core Web Vitals — Understanding Lab vs. Field Data

Redaktion ·

Core Web Vitals — Understanding Lab vs. Field Data

You open Lighthouse, hit start, and the page scores a perfect 100. All green. Two days later you check Search Console — and the very same URL sits at “needs improvement” for Core Web Vitals. No bug, no contradiction. You’re just looking at two completely different data sources, and that’s the single most common misconception in web performance.

There are two worlds in which Core Web Vitals get measured: lab (synthetic, one controlled run) and field (real users, statistically averaged over 28 days). Both have a purpose. But only one of them decides your ranking. Mix them up, and you can spend weeks tuning the wrong dial.

Lab data — the synthetic single measurement

Lab data comes from a controlled environment: a defined device, a defined network speed, a single run. The classic tool for it is Lighthouse — built into Chrome DevTools, into PageSpeed Insights, and into countless CI pipelines.

The big upside: lab data is reproducible. You change one line of code, reload, measure — and immediately see whether it got better or worse. No waiting for real users. That’s exactly why the lab is the right place to debug. Which image is blocking LCP? Which script shifts the layout? Which render blocker hangs in the <head>? Only a controlled run, where you turn one variable at a time, can answer that.

The big downside: the lab is a fiction. It knows no browser cache, no bfcache, no A/B tests, no real click patterns. It measures one device on one network in one location. Your actual users sit on three-year-old Android phones in a 4G dead zone, on gigabit fiber at a MacBook, and on everything in between. The lab simply doesn’t capture that distribution.

Field data — what real users actually experience

Field data (also called Real User Monitoring) comes from actual visitors. Google’s public source for it is the Chrome User Experience Report (CrUX) — anonymized performance data from Chrome users who opted in to sharing. This data feeds Search Console and the field section of PageSpeed Insights.

Field data isn’t a single measurement, it’s a distribution. Two key numbers you need to know:

  • 75th percentile (p75): A page passes a Core Web Vitals criterion when at least 75% of page loads hit a “good” value (source: corewebvitals.io, as of 2026). Not the average, not the median — the experience of the slower three quarters. That’s deliberately strict: it doesn’t ignore the slow half (as the median would), but it also won’t let a handful of outliers on terrible networks tank the verdict.
  • 28-day window: CrUX computes that p75 value over the last 28 days, rolling. It’s not an artificial delay but a smoothing step — it filters out daily noise and isolated traffic spikes.

The price of all that realism: field data reacts slowly. You ship a fix today, but the 28-day window takes weeks before the new state fully propagates. And: if you have too little traffic, your URL won’t appear in CrUX at all — then there simply is no field data for it.

Why only field data counts for rankings

This is the crux. Google evaluates page experience based on real user experience — that is, field data from CrUX. Your Lighthouse score, however green, feeds into no ranking. It’s a diagnostic tool, not a grading tool.

It makes sense once you separate the two cleanly: Google doesn’t care how fast your page could be under ideal conditions. Google cares how fast it actually is for the people who load it. A perfect lab score on a page that punishes real users on weak devices is worthless for the verdict.

INP exists only in the field

One special case makes the difference especially tangible: INP (Interaction to Next Paint), the official responsiveness metric since March 2024, replacing FID. INP measures how long a page takes to visibly respond to a user interaction — click, tap, keypress.

And that’s precisely what a classic lab run cannot measure. Lighthouse loads the page and measures what happens during load. But when a user clicks which button is something no synthetic run can know in advance. INP only materializes once someone actually interacts. That’s why INP appears in the field section but not in the classic lab score — you need real users to see it at all.

LCP and CLS, by contrast, get measured in both worlds — just with the caveats described above for the lab variant. The current “good” thresholds (as of 2026): LCP under 2.5 s, INP under 200 ms, CLS under 0.1.

Which tool for what — the practical cheat sheet

Three tools, three jobs — and the confusion almost always comes from mixing them up:

  • PageSpeed Insights — shows both. Field data on top (“what your real users experience”), the Lighthouse lab run with diagnostics below. Rule of thumb: read the field section first, it’s the one that decides. Since December 2024 it also displays the dates of the CrUX window.
  • Lighthouse / Chrome DevTools — pure lab. Your debugging tool. This is where you find out why a value is bad and test fixes in seconds.
  • CrUX Dashboard / CrUX API + Search Console — pure field. This is where you evaluate whether your page actually passes. Search Console also groups URLs by status and shows which URL groups fall below the threshold.

The clean workflow: spot in the field that a problem exists. Find out in the lab what causes it. Verify in the field that the fix really landed a few weeks later. Lab and field aren’t competitors — they’re two phases of the same process.

How this performance layer fits the bigger picture is covered in the overview on technical SEO.

FAQ

My page scores 100 in Lighthouse — does that mean my Core Web Vitals pass? No. Lighthouse gives you lab data, a synthetic single measurement under ideal conditions. Pass or fail is decided by field data from CrUX, measured at the 75th percentile of real users over 28 days. A perfect lab score can coexist with poor field values.

Why don’t I see any field data for my URL? CrUX needs a minimum amount of real traffic to form a statistically reliable distribution. If a single URL has too few visits, it’s missing from the dataset — then PageSpeed Insights falls back to the origin average or only shows the lab section.

I shipped a fix yesterday — why isn’t the field value changing? Field data runs over a rolling 28-day window. Your fix takes effect immediately for new visitors, but the reported p75 still blends old and new measurements for weeks. The improvement only fully propagates once the old window has cycled through completely.

Why can’t INP be measured in the lab? INP measures response time to real interactions — clicks, taps, keypresses. A lab run loads the page but can’t know when and what a user will click. That’s why INP exists only as a field metric; it doesn’t appear in the classic Lighthouse run.

What is the p75 value and why not the average? The p75 is the value that 75% of page loads reach or beat. Google uses it instead of the average because a mean smooths slow users away, while the median ignores the slower half entirely. The 75th percentile is the compromise: strict enough to surface real problems, robust enough against isolated outliers.

Themenuebersicht

Technisches SEOCore Web VitalsPageSpeed & Performance