Someone on the team runs PageSpeed Insights, screenshots the 95, and drops it into the monthly report. A fortnight later Search Console emails to say a group of your URLs has poor Core Web Vitals. Nobody touched the site in between.
Both reports are right. Why your Lighthouse score doesn't match Search Console comes down to a single distinction that almost nobody explains before you go looking for it: one number is a simulation, and the other is a record of what happened to real people.
The 95 is a laboratory result
Lighthouse loads your page once. It does that on a throttled connection, on a simulated device, from wherever the test is being run, with nobody clicking anything. The whole point of that setup is to hold the variables still so you get the same answer twice in a row. Google's own documentation on why lab and field data differ is blunt about the trade-off: controlling for the variables is what makes a lab test repeatable, and it is also what makes it unlike a real visit.
Search Console is reading something else entirely. It reports the Chrome User Experience Report, which is field data collected from actual Chrome users, aggregated on a 28-day rolling window. Real phones. Real networks on a train. Real people who tapped a menu before the page had finished settling.
So the score and the report are not competing claims about the same thing. One is a rehearsal. The other is the performance, with an audience.
The 75th percentile is doing the damage
This is the part that catches most teams out.
Core Web Vitals are not assessed on your average visit. Google takes the 75th percentile of real page views and checks that against the thresholds: 2.5 seconds for Largest Contentful Paint, 200 milliseconds for Interaction to Next Paint, 0.1 for Cumulative Layout Shift. All three have to pass.
Read that again with your own traffic in mind. Your slowest quarter of visits decides the verdict. If three quarters of your audience is on decent hardware in a city and the rest are on older Android phones with two bars of signal, the second group is the group being measured. Your office wifi and your MacBook are, statistically, not the customer.
That is also why the two numbers can drift apart without any code changing. Run a campaign that shifts your traffic mix toward mobile, or toward a country you were not previously reaching, and the field data moves while the lab score sits exactly where it was.
INP is the metric a lab test barely sees
Largest Contentful Paint is about loading, and a synthetic run measures it reasonably well. Interaction to Next Paint is about what happens after: you tap, and the page has to visually respond. INP replaced First Input Delay in March 2024, and it looks at interactions across the whole visit rather than only the first one.
A single automated page load does almost none of that. Nothing opens the mobile nav, filters the product grid, expands the FAQ accordion or submits the form. So the responsiveness problem your customers hit forty seconds into the session is invisible to the tool that gave you the 95.
In our experience this is where the ugliest gaps live. The page paints fast and then feels stuck, because the main thread is busy running scripts that were loaded on the assumption nobody would touch anything for a while.
Where the gap usually comes from
When we audit a site with a good score and a failing report, the causes repeat:
- Third-party scripts that fire after consent. The lab run often declines or never sees the cookie banner, so the chat widget, heatmap tool and two pixels never load. Your actual visitors accept, and then load all four.
- The cookie banner itself. It appears a beat after the content, pushes the page down, and books you a layout shift on nearly every session.
- Hero images sized for a desktop that nobody is using. A 2,400px image delivered to a 390px screen is a slow LCP that a fast test connection hides.
- Fonts that block the text. The layout is ready, the words are not, and LCP waits.
- Client-side rendering for content that never changes. The framework ships, boots, then fetches the thing that could have been in the HTML.
- Personalisation and A/B testing scripts. These deliberately delay paint so the user does not see the original version first. That is the mechanism working as designed, and it costs you seconds at the 75th percentile.
None of these are exotic. Most were added by a marketing team with a good reason, one at a time, over eighteen months, with nobody watching the cumulative bill.
What to do instead of chasing the score
Stop optimising the number you can control and start looking at the one Google uses.
- Open the Core Web Vitals report in Search Console first. It groups URLs by similar issues, which tells you whether you have a template problem or a page problem. A template problem is one fix. A page problem is a content review.
- Split mobile and desktop before you conclude anything. They pass and fail independently, and mobile is usually the one carrying the failure.
- Get real user monitoring on the site. Field data from your own visitors, tied to your own page templates, tells you which interaction is slow. CrUX tells you that something is; RUM tells you what.
- Audit the third-party scripts as a group, not one at a time. Ask who owns each one and what decision it feeds. The honest answer is usually that two of them have not been looked at since the person who added them left.
Then fix in that order, and re-check after 28 days rather than after the next deploy. The field data window means improvements land slowly, which is uncomfortable when someone wants proof by Friday. Set that expectation early.
There is a wider version of this problem, and it is the same instinct behind building pipelines that don't break at 3am: a number that is easy to measure quietly replaces the number that matters, and everyone optimises the proxy. Lighthouse scores are one of the cleanest examples on the web.
One thing you can do tomorrow
Open Search Console, go to the Core Web Vitals report, switch to Mobile, and write down how many URLs sit outside "Good". That figure is your actual starting position. Compare it to whatever score is in your last performance report, and you will know within a minute whether your site has a speed problem or a measurement problem.
If the gap is large, the fix is usually structural rather than cosmetic: what renders on the server, what loads on consent, what the page does before it is interactive. That is the layer we work in when we build and rebuild sites, and it is worth agreeing what you are measuring before anyone starts moving code.