Lighthouse Green, Search Console Red: Which CWV to Trust

#The complaint

"My site scores 95 in PageSpeed Insights and Search Console says it needs improvement. Which is wrong?"

Neither. They measure different things, and only one of them affects rankings. Understanding the difference is most of the way to fixing it, and it is the first thing we explain on every Core Web Vitals audit.

#Lab data versus field data

Lighthouse is lab data. It loads your page once, on a simulated mid-range phone, on a simulated slow connection, from a data centre, and reports what it saw. It is repeatable and it is fast to run. It is also a single synthetic visit that never clicks anything, never scrolls, never has an ad blocker or a cold cache or a flaky train connection.

Search Console is field data. It reports the Chrome User Experience Report, CrUX, which is the 75th-percentile experience of real Chrome users who visited your site over the past 28 days. Slow phones, bad networks, third-party scripts that only fire after a click, the lot.

Google's ranking systems use field data. Lighthouse is a diagnostic tool. A green Lighthouse score with red field data means the site is fast in ideal conditions and slow for a quarter of your actual visitors, and it is those visitors Google is describing.

#Why they disagree, metric by metric

LCP, Largest Contentful Paint. Lab LCP is often better than field because the lab has a warm data centre connection and no cookie banner. Field LCP is worse when the hero image is large, when fonts block text, or when a consent banner or chat widget becomes the largest element for real users.

INP, Interaction to Next Paint. This is where the two diverge most, because Lighthouse barely measures it. INP is the delay between a real user's tap or click and the next frame. Lab tools do not tap. Field INP exposes the analytics tag that runs a hundred milliseconds of JavaScript on every click, the React hydration that blocks the main thread for the first two seconds, the accordion that re-renders the page. A perfect Lighthouse score tells you nothing about INP.

CLS, Cumulative Layout Shift. Lab CLS measures shifts during load. Field CLS keeps counting while the user scrolls and interacts, so late-arriving embeds, ads, and fonts that swap after a scroll all count in the field and not in the lab.

#Which one to audit against

The field. Always. The lab is for reproducing a problem once you know it exists.

Practically, that means starting in Search Console's Core Web Vitals report, noting which metric fails and on which group of URLs, then opening PageSpeed Insights for a failing URL and reading the field data section at the top, not the Lighthouse score below it. PSI shows both; most people scroll past the one that matters.

If the field section says "not enough data", the page does not have enough Chrome traffic for CrUX. Then you need your own real-user monitoring, which is a small script that reports the same metrics from your actual visitors. Vercel Speed Insights, web-vitals with your analytics, or a dedicated RUM tool all do it.

#Reproducing a field problem in the lab

Once the field tells you INP is failing on mobile, the lab becomes useful again, with adjustments.

• Throttle harder than the default. Lighthouse's mobile preset is a mid-range phone. Your 75th-percentile user may be on something slower. Chrome DevTools lets you set 6x CPU throttling.
• Interact. Record a performance trace, then tap the things users tap: the menu, the booking button, the accordion. Look for long tasks after each interaction.
• Load with the third parties on. Lab runs often block or skip the tag manager, the chat widget, the consent script. Real users get all of them. Test with them.
• Test a cold cache and a cold origin. The first visit is the one CrUX mostly sees.

#The fixes that move field data

From twenty-odd audits, the changes that reliably moved field metrics, roughly in order of frequency:

1. Third-party scripts on the interaction path. Tag managers, session replay, chat widgets and A/B tools loaded early and running on every click. Deferring them past first interaction, or loading on intent, is the biggest INP win available.
2. Hydration cost. In React and Next.js apps, the main thread is busy hydrating while the user's first tap waits. Smaller client bundles, fewer client components, and streaming the non-critical parts fix it.
3. The LCP image not discoverable. Background images in CSS, lazy-loaded heroes, or images behind a client-side render. Make the LCP element a plain img in the HTML with fetchpriority="high", or preload it.
4. Fonts. Web fonts without size-adjusted fallbacks shift text when they arrive. font-display: swap plus matched fallback metrics removes the CLS.
5. Consent banners and late embeds. Reserve the space, or render them in a way that does not push content.
6. Server response time. Slow TTFB puts a floor under LCP that no front-end work can lower. Caching at the edge, or fixing the slow database query behind the page, is the fix.

#Proving the fix

Field data lags. CrUX is a 28-day rolling window, so a fix shipped today takes weeks to fully show in Search Console. Do not conclude a fix failed after a week.

Use your RUM data for the short term, and compare like with like: the same URL group, the same device class, two matched date ranges. Report the 75th percentile, not the average, because the 75th percentile is what Google reports and averages hide the slow tail you are trying to fix.

#What an audit should deliver

A Core Web Vitals audit worth paying for starts from the field data, names the metric and the URL group, reproduces the problem in the lab with the third parties on, lists the causes in order of impact with the evidence for each, and estimates the gain. It ends with a measurement plan, so that in six weeks you can say the number moved and by how much.

A Lighthouse screenshot with generic advice is not that. If you have one of those and a red Search Console report, the audit is here, and it is priced separately from the fixes so you can hand the findings to your own team.