A team runs Lighthouse, sees 96, and declares the performance work done. Three months later Search Console still reports URLs failing Core Web Vitals. Both are correct. They are measuring different things.
Two fundamentally different datasets
Lab data — Lighthouse, PageSpeed Insights' simulated section, WebPageTest — loads your page in a controlled environment: a specific device profile, a throttled network, a cold cache, no extensions, no real user behavior. It is reproducible and diagnostic. It is also a simulation of one hypothetical visit.
Field data — the Chrome User Experience Report, and the "real user" section of PageSpeed Insights — aggregates measurements from actual Chrome users who opted into reporting, over a rolling 28-day window. It reflects real devices, real networks, real caching, real interaction.
Google's page experience signals use field data. Lab data is a debugging tool, not the scoreboard.
Why they diverge
Device and network mix. Your lab test runs one profile. Your real traffic runs everything from current flagships on fibre to four-year-old mid-range Android on congested mobile networks. CrUX reports the 75th percentile, so the slowest quarter of your visitors sets your score. A site whose median experience is excellent can fail on the tail.
Real interaction. Interaction to Next Paint measures responsiveness to actual user input across the whole session. A lab test that loads the page and stops never generates the interactions INP exists to measure. This is the single most common source of "great lab score, failing field data."
Caching and repeat visits. Lab tests typically run cold. Real traffic is a mix of first and repeat visits, and the mix differs by page type.
Geography. Your test runs from wherever your tooling lives. Your users are wherever they are, and physical distance to origin is a real component of load time.
The 75th percentile trap
Core Web Vitals thresholds are evaluated at the 75th percentile of page loads. This is much stricter than an average, and it produces a specific failure mode: a page can have an excellent mean and still fail, because a minority of slow experiences drags the percentile past the threshold.
Practically this means you should stop optimizing the typical visit and start finding the slow tail. Real user monitoring that captures the distribution — not just the average — is what tells you whether the slow quarter is a device problem, a geography problem, a specific page template, or a third-party script that only fires under some conditions.
The metrics, and what usually causes each to fail
Largest Contentful Paint — time until the largest content element renders. Usual culprits: unoptimized hero images, render-blocking CSS and fonts, slow server response, client-side rendering of the main content.
Interaction to Next Paint — responsiveness across the session, replacing First Input Delay. Usual culprits: long JavaScript tasks blocking the main thread, heavy event handlers, oversized hydration work on framework-driven pages. This is where most sites now fail, and it is the metric least visible in a standard lab run.
Cumulative Layout Shift — visual stability. Usual culprits: images and iframes without dimensions, ads and embeds injected above existing content, web fonts causing reflow, cookie banners appearing late.
The URL-group problem in Search Console
Search Console reports Core Web Vitals by "URL group" — clusters of similar pages — rather than per URL, because CrUX needs sufficient traffic volume to report. Low-traffic URLs get grouped with structurally similar ones, and pages with too little data get no field data at all.
Two consequences follow. First, fixing one URL in a failing group may not move the group until enough of its members are fixed. Second, for genuinely low-traffic pages, you will never see field data, and lab data plus good engineering judgment is all you get. That is a legitimate use of Lighthouse.
The honest weighting
Core Web Vitals are a ranking signal. They are also a modest one, and Google has consistently described them as a tiebreaker rather than a primary factor — relevance and content quality dominate. A slow page with the best answer generally outranks a fast page with a worse one.
That does not make the work pointless, because the conversion and bounce effects of performance are real and often larger than the ranking effect. But it does mean the sequencing matters: if a page is not ranking, performance is rarely the reason, and reordering the roadmap to chase a Lighthouse number while the content problem goes unaddressed is a common and expensive mistake.
Measure with field data, debug with lab data, and fix performance because it makes the site better — not because you expect a ranking jump from 96 to 99.