New: SEO & AEO scanning — see how Google ranks you and how ChatGPT, Claude & Perplexity cite youSee how it works
You run Lighthouse: 94. You check Search Console: "LCP issue: longer than 2.5s (mobile)." Both are measuring the same site on the same day. Neither is broken.
This is the lab-versus-field gap, and misreading it is the most common way developers waste a performance sprint — optimizing a number that was already fine while the one hurting their rankings stays red. Here's how the three kinds of performance data actually relate, and how to use the disagreement between them as a diagnostic instead of a confusion.
Google's Core Web Vitals are three user-experience metrics with official thresholds, measured at the 75th percentile of real page loads:
| Metric | Measures | Good | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Time until the main content renders | ≤ 2.5s | > 4.0s |
| INP (Interaction to Next Paint) | Worst-case responsiveness to taps/clicks/keys | ≤ 200ms | > 500ms |
| CLS (Cumulative Layout Shift) | Visual stability — how much the page jumps | ≤ 0.1 | > 0.25 |
Two supporting metrics — TTFB (≤ 800ms good) and FCP (≤ 1.8s good) — aren't ranking inputs themselves but explain the others: a slow LCP with a slow TTFB is a server problem; a slow LCP with a fast TTFB is a frontend problem.
Lab data is your site measured by a tool, under fixed conditions, right now. Lighthouse, PageSpeed Insights' top section, WebPageTest, and scanner probes are all lab.
Strengths: instant feedback, perfectly reproducible, available before launch and on staging, and it can see causes — render-blocking scripts in the <head>, images without dimensions, missing compression, redirect chains, cache headers, font-display strategy. Lab is where you debug.
Blind spots: a lab run is one synthetic visitor with one device, one network, an empty cache, and no interactions. It cannot measure INP meaningfully (nobody is interacting), and it will happily report a fast LCP from a datacenter while your actual users load the page on a mid-range Android over cell data, three network hops and one continent away.
Field data is aggregated from actual Chrome users via CrUX (the Chrome UX Report). It's what Google uses for ranking. PageSpeed Insights' "Discover what your real users are experiencing" section, Search Console's CWV report, and the CrUX API all read from it.
The shape of CrUX matters as much as the numbers:
Real User Monitoring closes CrUX's gaps: a small script on your own pages reports each real visit's LCP, INP, CLS, FCP, and TTFB. You get per-page, same-day resolution instead of a 28-day origin-level blur — RUM is how you see yesterday's deploy hurt INP on one specific route, weeks before CrUX would average it into visibility. CrUX remains the scoreboard that rankings read from; RUM is the live telemetry that tells you what to fix today.
The lab/field gap isn't noise — it's information. Each combination points somewhere specific:
| Lab | Field | What it means |
|---|---|---|
| Fast | Slow | Your conditions are the problem: real devices and networks are slower than the probe. Look at payload size, image weight, JS execution cost on mid-range mobile — and check whether CDN coverage matches where your users actually are. |
| Slow | Fast | Often fine. Caches, returning visitors, and geographic proximity help real users in ways a cold lab run doesn't see. Confirm with RUM before spending a sprint on it. |
| Fast | Fast | Ship features. Set a budget so you notice when this changes. |
| Slow | Slow | Believe it. Use the lab's cause-level findings to fix it, and watch field data confirm over the following weeks. |
For LCP specifically, the highest-leverage diagnostic is the phase breakdown: total LCP splits into TTFB → resource load delay → resource load duration → element render delay. A 3.8s LCP that's 2.9s TTFB is a backend/CDN ticket; the same 3.8s spent in resource load delay means the browser discovered your hero image too late (lazy-loaded above the fold, or buried behind a JS render) — a completely different fix.
Performance isn't a project, it's a property — and properties decay. A marketing script lands, a hero image doubles, a dependency upgrade ships 80KB of polyfills. Each one is invisible in code review and obvious in field data — three weeks later, when CrUX catches up and rankings have already moved.
A regression watch closes that gap. The mechanics that make one trustworthy rather than noisy:
We built the performance check around the lab/field/RUM triangle rather than another isolated Lighthouse score:
It lives alongside uptime and the security scanners in the same project, because "the site is slow" and "the site is down" are the same conversation at different volumes.
Run a free scan and the lab layer runs immediately; field data appears for any origin Chrome has enough traffic data on.
Lighthouse is lab data — one synthetic load under fixed conditions, usually from a fast machine in a datacenter. Search Console reads CrUX field data — the 75th percentile of your real users over 28 days, separately for phone and desktop. Real users on mid-range phones over cell networks are slower than the lab probe. Both are correct; they answer different questions.
Field data decides whether you have a problem — it's what users experienced and what Google ranks on. Lab data tells you why and verifies fixes instantly. Use field to prioritize, lab to debug, and RUM to see results same-day instead of waiting out CrUX's 28-day window.
CrUX is a 28-day rolling window, so a fix shipped today reaches full effect in about four weeks, moving gradually as old days roll out of the window. RUM shows the improvement within hours — which is exactly why you want both.
200ms or less at the 75th percentile counts as good; over 500ms is poor. INP replaced FID in March 2024 and is stricter — it measures your worst interactions across the whole visit, not just the first. Long JavaScript tasks on the main thread are the usual culprit.
Yes — as one signal among many, evaluated per URL, with the biggest effect in competitive results and on mobile. Relevance still dominates: vitals are a tiebreaker between comparable pages, not a way to outrank better content. The indirect effects (bounce rate, conversion) are typically larger than the direct ranking lift.
Paste your URL and get a security report in 30 seconds. 100+ automated checks with AI-powered fix prompts.
Scan your site free