Lighthouse vs field data: check that your fix worked

Lighthouse says it's fixed. Why is Search Console still red?

Lighthouse loads your page once, on one simulated phone, and reports LCP and CLS for that load. Your Core Web Vitals are field data: the 75th percentile of 28 days of real Chrome visits, on fast and slow phones and networks, with empty and full caches, including every click. So a fix can pass in Lighthouse today and take four weeks to show in Search Console. Compare three Lighthouse runs, then watch your field data.

How do you run Lighthouse so you can compare before and after?

Run Lighthouse the same way before and after the change:

1. Clear the caches. Empty the cache of your caching plugin and your CDN after the change, or Lighthouse tests the old page.
2. Pick one tool and keep it. Without code: PageSpeed Insights, on the Mobile tab. As a developer: the Lighthouse panel in Chrome DevTools with Device set to Mobile, in an incognito window, because browser extensions add their own scripts to the page.
3. Test the URL that had the notice. When the change was in the product template, test a product page.
4. Run it three times and take the middle result.
5. Look at the notice and its metric first. The notice moves to Passed audits, and the metric it was about (LCP, CLS, Total Blocking Time) goes down. The score comes last.

Why does the score change when nothing changed?

Every run is one load, and no two loads are the same: the server answers faster or slower, the network varies, and ads, consent banners and A/B tests can differ from run to run. On one of my test pages the first text or image (FCP) appeared 1.5 s earlier in one run than in another, and on a second page the score came out at 96 or 80 with nothing changed. A few points up after a fix tells you little until you compare the middle of three runs.

Six runs in a row on the same URL, www.bbc.com, scored 38, 44, 41, 73, 60 and 53 within two minutes. Lighthouse 13.5.0, mobile, simulated throttling as in PageSpeed Insights.

Recording a trace in DevTools

Open the page in Chrome, open DevTools and go to the Performance panel. In Capture settings (the gear icon), set Network to Slow 4G and CPU to 4x slowdown, close to what Lighthouse simulates on mobile, then click Record and reload. The Insights tab in the sidebar lists the same insights as Lighthouse, each with the requests and elements behind it. Before you record, the panel shows your own LCP, CLS and INP live (INP once you click in the page). Click Set up under Field metrics and it puts the CrUX numbers of your real visitors for the same URL next to them.

Why does Lighthouse say one thing and Search Console another?

Lighthouse gives you lab data: one load of your page on a simulated mid-range phone over a slow 4G connection, with an empty cache. It stops shortly after the load, so it never scrolls, taps or opens a second page. You get LCP and CLS for that one load, and no INP, because INP needs a visitor who clicks.

Field data is what Chrome measured for your real visitors: fast and slow phones, good and bad networks, a first visit with an empty cache and the tenth with everything cached, scrolling, tapping, going from page to page. Google collects it in the Chrome UX Report (CrUX), from Chrome users on Android and desktop who share usage statistics. Your Core Web Vitals are those visits over the last 28 days, per metric at the 75th percentile (p75): three out of four visits were at least this good.

Google ranks on the field data. Lighthouse is for finding out why a page is slow and whether a change helps. When the two disagree, they measured different loads. A green Lighthouse score with poor field data often means phones slower than the simulation, slow responses to clicks (INP) or content that shifts while visitors scroll. A red score with good field data often means your visitors have faster phones and networks than Lighthouse's slow 4G, and come back with your files in their cache.

One PageSpeed Insights report for www.bbc.com on mobile, 26 October 2026. The real visits pass all three Core Web Vitals with an LCP of 1.2 s; the Lighthouse run in the same report scores 37 with an LCP of 9.5 s.

PageSpeed Insights shows the field data for the URL you tested when that URL has enough visits, and for the whole site under Origin when it doesn't. Search Console puts similar URLs in groups and rates each group by its worst metric.

Where do you see what your visitors got?

Four free tools show CrUX, the field data Google uses:

• PageSpeed Insights: the top section, "Discover what your real users are experiencing", with LCP, INP and CLS at p75 for the last 28 days, for the URL or the origin.
• Search Console: the Core Web Vitals report, for mobile and desktop, shows which groups of similar URLs are poor across the whole site.
• CrUX History report: a bar per week for your site or a URL, so you see the trend.
• DevTools: the Performance panel puts the same numbers next to your own load (set up once).

A site with too few Chrome visits has no CrUX data: PageSpeed Insights shows "No Data" in the top section. CoreDash measures those visits anyway.

CoreDash: which page, which element

CrUX, Google's field data, gives you one p75 per URL or per site. CoreDash, the real user monitoring I built, is a script on your pages that measures every visit and names the element behind every LCP, INP and CLS. You filter by page, device and element, and a change shows in the time series from the next visits on. Add the script before you change anything, so you can compare before and after.

CoreDash, acme-pagespeed.com, mobile, p75 per page: one page has a CLS of 0.92 where the rest have 0.

How long until Search Console shows your fix?

PageSpeed Insights and Search Console show the last 28 days, and that window moves every day. In PageSpeed Insights the data is about two days old, in Search Console a few days older. Two weeks after your fix, half of the visits in that window are still from before the fix. After four weeks it holds only visits from after the fix. The 28-day window, day by day has the full timeline.

Search Console, Core Web Vitals report, mobile, on 26 October 2026: last updated on 21 October.

The CrUX History report shows the same window per week: each bar covers the 28 days before it, so a fix takes about four bars to show in full.

CrUX History report for ado-goldkante.de, phones, LCP: the share of good, needs improvement and poor loads per week. After a change in mid August the good share climbs from 59% over four bars, to 76%, 83%, 90% and 93%, and p75 LCP goes from 3.6 s to 1.5 s.

When the fix is live, open the issue in Search Console's Core Web Vitals report and click Start Tracking (also called Validate fix). That starts Search Console's own 28-day check of every URL with that issue, on the same field data. While it runs the status is Started, then Looking good once every URL checked so far is fine. It ends at Passed when no URL had the issue for 28 days, or at Failed when one still has it; then you fix that and click Start new validation.

How do you know a fix worked for real visitors?

Check in this order, fastest first:

1. The change is live. View the page source, or find the file or header in the DevTools Network panel. If you still see the old version, a caching plugin or the CDN is serving the old page.
2. Lighthouse passes. Mobile, three runs, the middle one (as above): the notice moves to Passed audits.
3. Your visitors get it. In CoreDash, from the next visits on: filter the page or template you changed, set the device to mobile, and follow the metric per day and the element behind it.
4. CrUX follows. The field data in PageSpeed Insights and the bars in the CrUX History report move a little at a time. The full effect shows after four weeks (why it takes that long).
5. Search Console confirms it. In the Core Web Vitals report, click Start Tracking on the issue and wait for Passed.

Lighthouse passes, four weeks have gone by and your field data still hasn't moved? Then the slow visits are ones Lighthouse never makes: a cheaper phone, a slow click, a shift halfway down the page. In a Core Web Vitals power hour I go through your field data with you, page group by page group, until we know which page and which element hold your p75 back.