Core Web Vitals: Why a Perfect Lighthouse Score Still Fails

This is the most common confused email I receive: "Lighthouse says 98. Search Console says we fail Core Web Vitals. Which one is lying?"

Neither. They measure different things, and only one of them affects your rankings.

Lab data versus field data

Lab data is what Lighthouse and PageSpeed Insights' top section produce. One page load, on a simulated device, on a simulated network, in a controlled environment. It is a diagnostic tool — reproducible, useful for debugging, and completely artificial.

Field data is the Chrome User Experience Report (CrUX). It is aggregated from real Chrome users who visited your site, on their actual devices, on their actual connections, doing whatever they actually did on the page. It is reported at the 75th percentile over a rolling 28-day window.

Google uses field data for the ranking signal. Lab data is not part of it.

So when Lighthouse says 98 and Search Console says fail, both are correct. Your site is fast on a simulated mid-tier phone on a clean network. It is slow for the quarter of your real visitors having the worst experience.

Why the gap exists

Five causes account for nearly every discrepancy I find.

Your real users are on worse devices

Lighthouse's mobile emulation is generous. If a meaningful share of your traffic is on older Android hardware, their JavaScript execution time can be four to five times what the simulation assumes. Nothing about your code is wrong — the assumption was.

The 75th percentile is not the average

This catches almost everyone. CrUX reports the experience at the 75th percentile, meaning one in four visits must still pass. Your median can be excellent while the tail fails. Optimising the average changes nothing; you have to fix the slow quarter.

Lighthouse does not interact with your page

INP — Interaction to Next Paint — measures responsiveness to real clicks, taps and key presses. A lab test loads the page and stops. It never opens your mega-menu, never types in your search box, never triggers the handler that blocks the main thread for 400ms. Field data captures all of it.

Cold cache versus warm cache

Lab tests run cold. Real traffic is a mix, and if your repeat-visitor caching is misconfigured, returning users can be slower than first-time ones — the opposite of what you would assume.

Third-party scripts behave differently in the wild

Your tag manager, chat widget, ad scripts and analytics all behave predictably in a lab run. In production they contend for the main thread against each other, at different times, under real network conditions.

What to fix, in order

1. LCP — Largest Contentful Paint

Target: under 2.5 seconds at the 75th percentile.

The LCP element is usually a hero image or a headline. The fixes, in order of impact:

• Preload the LCP image. <link rel="preload" as="image"> with the correct imagesrcset. This alone routinely takes a second off.
• Never lazy-load it. loading="lazy" on a hero image is actively harmful, and it is extremely common because someone applied it site-wide.
• Serve modern formats — AVIF or WebP, correctly sized for the viewport.
• Remove render-blocking resources in the head. Inline critical CSS, defer the rest.
• Check your TTFB. If the server takes 800ms to respond, no front-end work will save you.

2. INP — Interaction to Next Paint

Target: under 200 milliseconds.

INP replaced FID in 2024 and is much harder to pass, because it measures the whole interaction rather than just the delay before handling begins.

• Break up long tasks. Anything over 50ms blocking the main thread will show up here. Yield with scheduler.yield() or split the work.
• Audit third-party scripts. Chat widgets and tag managers are the usual culprits. Load them on interaction rather than on page load.
• Avoid layout thrashing in event handlers — reading a layout property after writing to the DOM forces a synchronous reflow.
• Debounce expensive handlers, especially on scroll and input.

3. CLS — Cumulative Layout Shift

Target: under 0.1.

The easiest of the three to fix and the one people leave broken longest.

• Set explicit width and height on every image and video. This is a one-line fix with a large effect.
• Reserve space for ads and embeds with a fixed-height container.
• Use font-display: optional or preload your fonts so text does not reflow when the webfont arrives.
• Never inject content above existing content after load — cookie banners and promo bars are the repeat offenders.

How to actually measure it

Stop relying on the Lighthouse tab.

1. Search Console → Core Web Vitals report. This is field data grouped by URL pattern. It is the closest view to what Google acts on, though it lags by around 28 days.
2. PageSpeed Insights, top section only. The upper block is CrUX field data for that URL. The Lighthouse section below it is lab data. People read the wrong one constantly.
3. The CrUX Dashboard for trends over time rather than a single snapshot.
4. Real user monitoring using the web-vitals library if you want live data instead of a 28-day rolling window. On a site making changes weekly, this is worth the setup.

The realistic timeline

Field data updates on a 28-day rolling window. Deploy a fix today and Search Console will not fully reflect it for roughly a month, with partial movement starting after about a week.

This trips up a lot of teams. They ship a fix, check three days later, see no change, and assume it failed. Use real user monitoring if you need faster feedback — otherwise, ship and wait.

What this is actually worth

Be realistic about the size of the prize. Core Web Vitals is a real ranking signal, but it is a tiebreaker, not a primary factor. A fast page with weak content will not outrank a slow page that answers the query properly.

Where it genuinely pays is conversion. Every measurable study on the subject points the same direction: faster pages convert better. Treat Core Web Vitals as a revenue project that happens to also help rankings, and the effort justifies itself either way.