Lighthouse Tests One Load. Google Grades Every Real Visit.

The big coloured number in PageSpeed Insights is a lab estimate. It is not what Google grades. Ranking uses field data from the Chrome User Experience Report: real visits, real devices, real networks, assessed at the 75th percentile over 28 days. A page passes only when LCP, INP and CLS are all good. That is why a site can score 95 in the lab and still show red in Search Console.

Lab data is one simulated page load on a throttled device, run on demand. Field data is what actually happened to real Chrome users over the last 28 days. PageSpeed Insights shows both on the same screen, which is where the confusion starts.

The top section, when it appears, is field data from CrUX. The section below it is lab data from Lighthouse.

Lab data is a diagnostic. It tells you what is slow and in what order to fix it, and it is reproducible, which makes it useful in CI. Field data is the verdict. It drives your Core Web Vitals assessment in Search Console and feeds the page experience signal.

The two disagree constantly, for mundane reasons. Your lab test runs from a data centre near your server. Your users are on a mid-range Android phone, on a mobile network, two countries away, after marketing added three tag manager containers. Lab conditions are a clean room. Field data is the street.

Three metrics, unchanged in their good thresholds.

Four rules people get wrong:

One clarification, because it is circulating widely: several SEO blogs published claims in 2026 that Google cut the good LCP threshold from 2.5 to 2.0 seconds in a March core update, and that INP was promoted to a ranking signal at the same time. Neither matches Google's own documentation. INP replaced First Input Delay on 12 March 2024 and has carried the same weight as the other two since. The three good thresholds have not moved. If someone is selling you an emergency based on a threshold change, ask for the Google source.

LCP, and specifically on mobile. Loading is the problem, not responsiveness or layout shift.

The 2025 HTTP Archive Web Almanac performance chapter, published January 2026 on CrUX field data from July 2025, found that 48% of mobile origins and 56% of desktop origins passed all three Core Web Vitals. Mobile has improved steadily, from 32% in 2021 to 44% in 2024, but more than half the mobile web still fails.

The breakdown is the useful part. On mobile, 81% of sites record a good CLS and 77% a good INP, but only 62% manage a good LCP. On desktop the same metrics run 72%, 97% and 74%. Two things stand out: INP is close to solved on desktop and far from it on mobile, and mobile CLS is actually better than desktop, because narrower viewports shift less.

And LCP has a floor you cannot optimise past on the front end: server response time. If your server takes 800ms to send the first byte, no amount of image compression produces a 2.5-second LCP. Google's own guidance treats TTFB at or under 0.8 seconds as good and above 1.8 seconds as poor. It is not a Core Web Vital itself, but it constrains one, which is why a front-end performance sprint on a slow backend so often plateaus at needs-improvement. The Web Almanac found only 44% of mobile sites reach a good TTFB, against 55% on desktop. We wrote up a case where database lag went from 5 seconds to 100ms, where cart abandonment fell from 68% to 47% once the server stopped being the bottleneck.

This is where performance work usually dies. Engineering says LCP is 4.1 seconds. Finance hears a number with no currency attached and funds something else.

The bridge is arithmetic. Take monthly traffic, conversion rate and average revenue per customer to get current monthly revenue from the site. Then apply a documented behavioural multiplier to estimate what a share of that traffic is doing instead of converting.

The studies people cite for those multipliers are worth knowing by name, and worth reading as correlational rather than causal:

None of these are controlled experiments on your site, and anyone presenting them as a guarantee is overselling. What they give you is a defensible range, which is all a budget conversation needs.

If you would rather not build the spreadsheet, our website revenue loss calculator runs the same arithmetic in about 60 seconds from your traffic band, industry and average revenue per customer, and shows the multipliers it applies. It uses deliberately conservative figures and publishes its methodology, so a finance team can argue with the assumptions rather than the conclusion. Or start with a full website audit if you want the whole technical picture, not just the speed number.

Then make the case concrete: run the same check on a competitor. CrUX data is public. If your closest competitor passes on mobile and you do not, that is not a technical detail. It is a structural advantage they hold on every shared query, on every device, every month.