Your Lighthouse score is green. Why are your Core Web Vitals failing?

You run Lighthouse, or PageSpeed Insights, and the circle is green. Then Google Search Console emails you: Core Web Vitals issues detected. Same site, same week, opposite answers.

Neither tool is broken. They are measuring two different things, and only one of them is what Google uses for search.

The short answer

Lighthouse is lab data: one simulated page load, on one test machine, with a fixed network speed. It’s a good way to spot problems before you ship, and it’s repeatable, which is why developers like it.

Search Console shows field data: real visits from real Chrome users over the last 28 days, collected in the Chrome User Experience Report (CrUX). That’s the data Google’s page experience signal looks at. Your Lighthouse score isn’t part of it.

Lighthouse tells you what could happen. Field data tells you what did.

PageSpeed Insights shows both on one page, which is where a lot of the confusion starts. The section at the top, “Discover what your real users are experiencing”, is field data. The score circle below it is Lighthouse.

Five reasons they disagree

1. 01One visit versus thousands. Lighthouse loads the page once, with an empty cache. Your visitors arrive on every kind of phone, laptop and connection, and the slow ones count.
2. 02Lighthouse never taps anything. Interaction to Next Paint (INP) needs a real person clicking, typing or opening a menu. A lab run has no interactions, so it can’t measure INP at all. Total Blocking Time is a stand-in, and a rough one.
3. 03Lighthouse stops when the page loads. Field CLS keeps counting while people scroll and use the page: late ads, cookie banners, images without sizes, content that pops in. A lab run doesn’t see shifts that happen after load.
4. 04Real visits hit pages Lighthouse doesn’t test. Logged-in dashboards, search results, carts and product pages with real data. Lab tests usually run on the homepage or a few public URLs.
5. 05Real visits carry real baggage. Tag managers, chat widgets, A/B tests, personalisation and consent tools often behave differently, or don’t load at all, in a lab run.

Lab results aren’t always rosier. On a site whose visitors mostly use fast desktops, Lighthouse’s mobile run can be harsher than reality. The point is that the two numbers answer different questions.

How Google judges a page

Google takes the 75th percentile of each metric: the experience that three out of four visits beat, and one in four doesn’t. It’s not the average, so a slow quarter of your visits can fail a page even when most people had a fast one. Our animated p75 explainer walks through it.

Search Console groups similar URLs together and judges mobile and desktop separately. Pages without enough Chrome traffic of their own fall back to the group, or to the whole site. That’s why one slow template can mark hundreds of URLs as failing at once.

Why it shows up weeks late

CrUX is a rolling 28-day window. When a release makes a page slower, the bad visits only gradually outweigh the good ones, so Search Console turns red days or weeks later. By then you may have shipped ten more releases, and nobody remembers which one changed the page.

The same lag works in reverse. After you fix the problem, the old slow visits stay in the window, and it can take about four weeks for the report to go green again.

Find the release that did it

To connect a failing metric to a cause, you need your own field data, split by release. Put a small real-user monitoring script on the site, tell it which version is live, and compare the 75th percentile before and after each deploy, per page and per device.

That’s what CodeGecko does. Each release is compared with the one before it using real visitors. A metric is only called Regressed once both releases have at least 30 visits for that page and device, and the change is bigger than 5% or the metric’s floor. The report lists the commits that shipped, alongside what got heavier: load steps, long animation frames, bytes and third parties. The methodology has every rule, and the demo shows a release that regressed.

It counts every visit from browsers that report these metrics, not only Chrome users who share data with Google, and it doesn’t wait for a 28-day window. As soon as both releases have enough visits, often within days on a busy site, you get a verdict.

A checklist

• Read the field data first: the top of PageSpeed Insights, or the Core Web Vitals report in Search Console.
• Note which metric fails, on mobile or desktop, and which URL group.
• INP failing? Look for heavy click handlers, long tasks and third-party scripts. Lighthouse can’t show it, so test by using the page.
• CLS failing? Scroll the page and use it. Reserve space for images, embeds, ads and banners.
• LCP failing? Check server response time, the size of the main image and render-blocking CSS and fonts.
• Find when it started. If you can’t tell which release did it, start measuring per release now, so the next one can’t hide.

NourBuilding CodeGecko