Your Lighthouse Score Is Lying to You
The email arrived on a Tuesday morning, and the subject line made the business owner feel good about her week before she’d finished her coffee.
“Speed audit complete, you’re at 94. We’re in great shape.”
The screenshot showed a Google PageSpeed Insights report for her Tampa Bay e-commerce store. Big green circle. Score of 94. The SEO agency had been hired specifically to clean up a performance problem, and the number looked like proof the job was done.
Three months later, Google Search Console still flagged Core Web Vitals issues on her product pages. The agency had no explanation. The score had not moved. The problem had not cleared.
The score and the assessment were measuring two different things, using two different methodologies, against two different data sources. A 94 in Lighthouse tells you something real. It does not tell you whether you pass Core Web Vitals.
What Lighthouse Actually Is
Lighthouse is a lab tool. That is not a criticism, it is a description of the methodology.
When you run Lighthouse, through Chrome DevTools, PageSpeed Insights, or the command line, it does not look at what your real visitors experienced. It loads your page once, on a simulated device, under simulated network conditions, and scores what it observes in that single run.
According to DebugBear’s 2026 technical analysis, consistent with Lighthouse’s own documentation: Lighthouse throttles the connection to 1.6 Mbps with 150ms latency and the CPU by a factor of 4x to approximate a lower-end mobile device. These conditions match the bottom 5–10% of real users, not the median visitor, and certainly not the visitor on a modern phone on a fast home network.
But here is the more important gap, and the one that catches even experienced developers off guard.
Google Does Not Use Lighthouse to Grade Core Web Vitals
Google’s Core Web Vitals assessment, the one that appears in Google Search Console and in the field data section of PageSpeed Insights, is based on CrUX, the Chrome User Experience Report. CrUX collects actual performance measurements from real Chrome users on real devices with real connections, across all the real visits your site receives over a 28-day rolling window.
Google Developers’ own documentation on PageSpeed Insights (2024) is specific: the assessment passes if the 75th percentile of all three Core Web Vital metrics, measured from CrUX field data, are in the “Good” range. The 75th percentile means you need to pass for 75% of your actual visitors, not just the average, and not just under ideal conditions.
You can learn more about what fast enough means in 2026, including the exact thresholds each metric is graded against, but the key operational fact here is the source: Google grades field data, not lab scores.
This is why the retailer’s 94 Lighthouse score coexisted with ongoing Search Console failures. Lighthouse found no problems under its simulated conditions. CrUX found that 25% or more of real visitors were experiencing values above Google’s “Good” thresholds.
The score was not wrong. It simply was not answering the question she thought it was.
The Metric That Cannot Be Measured in a Lab at All
There is a deeper problem, and it is specific to INP, Interaction to Next Paint, which Google elevated to a Core Web Vital in March 2024. INP measures how quickly a page responds when a real user interacts with it: taps a button, types in a form field, opens a menu. It captures the delay between that human action and the moment the browser visually acknowledges it happened.
Google’s own documentation on web.dev (2025) states this plainly:
“INP can’t be measured in lab environments because it requires user interactions with the page. As a result, Total Blocking Time (TBT) is the recommended lab proxy for INP.”
Read that twice. A site can hold a perfect Lighthouse score of 100, every lab metric green, zero identified issues, and still fail Core Web Vitals in the field because of a poor INP score that no lab tool can see.
When you run Lighthouse, it shows you TBT: Total Blocking Time, which measures how long JavaScript is blocking the main thread during the page’s loading phase. TBT and INP are related, heavy JavaScript loading often produces heavy JavaScript interactions, but they are not the same thing. TBT measures what happens during loading. INP measures what happens when your visitor tries to use the page after it has loaded.
A form that loads in one second but takes 480ms to respond when someone taps a field will score well on TBT. It will fail INP in the field. And INP thresholds are strict: Google classifies anything above 200 milliseconds as needing improvement, and anything above 500 milliseconds as poor.
The Law Firm That Had Both Problems
Consider, as a worked scenario, a Tampa Bay law firm that ran a routine how to test website speed properly check using Lighthouse and came back with an 87. The score put them in a reasonable-looking range. Nothing alarming.
Their Google Search Console told a different story.
The Core Web Vitals report showed their contact page, a multi-step form built with a heavy JavaScript component, flagged as “Poor” for INP. The field data, aggregated from real visitors over the prior 28 days, showed a 75th-percentile INP of 620 milliseconds, three times Google’s Good threshold of 200ms.
What Lighthouse had seen: Total Blocking Time within acceptable range. The JavaScript was not blocking the main thread during loading in a way the lab could detect.
What real visitors experienced: a 620ms lag every time they tapped a form field. On mobile, that feels like a broken page. Many abandoned the form before completing it.
The 87 gave the firm’s coordinator false confidence. It was not until someone checked Search Console’s Core Web Vitals report and PageSpeed Insights’ field data panel, not the top-line score, that the actual picture emerged.
This is the RUM Core Web Vitals engineering guide’s (2026) core observation about lab-versus-field divergence: “A page can score 100 in the lab and still fail in the field, most often on INP, which a non-interactive lab run cannot measure.”
Where Lighthouse Is Useful
None of this means Lighthouse should be ignored. It means it should be used for what it is actually good at.
Lighthouse excels as a development diagnostic, identifying which resources slow loading, flagging render-blocking scripts, surfacing oversized images. Every code change can be validated in Lighthouse before deploying. It is also the right tool for regression testing: confirming a new feature deployment has not made performance worse before real users encounter it.
What Lighthouse is not is evidence of CWV compliance. For an SMB wanting to understand the minority of mobile sites that pass Core Web Vitals, and where their own site sits in that population, the right sources are PageSpeed Insights’ field data panel, Google Search Console’s Core Web Vitals report, and CrUX Vis, Google’s current visualization tool for the Chrome User Experience Report.
Google’s own PageSpeed Insights documentation (2024) makes this practical: the field data section and the score live on the same page in two separate sections. Only one of them is how Google grades your site.
The One Check That Settles It
Open PageSpeed Insights and run your URL. Before you look at the circular score at the top, scroll down to the section labeled “Discover what your real users are experiencing.” That is the field data. It shows your 75th-percentile LCP (Largest Contentful Paint, how long your main content takes to appear), INP (how quickly the page responds to taps and clicks), and CLS (Cumulative Layout Shift, how much the page moves around during loading).
If you have field data, those numbers tell you your actual CWV status. If a row shows “Poor” or “Needs Improvement,” you have a real problem regardless of what the Lighthouse score says.
If you do not have field data, if Google shows “The Chrome User Experience Report does not have sufficient real-world speed data for this page”, your site does not have enough Chrome traffic for CrUX to aggregate. In that case, putting a dollar figure on your load time becomes harder without setting up your own real-user monitoring first.
What to Do With This Information
If your developer has told you your Lighthouse score proves you’re fine, show them the field data panel in PageSpeed Insights. If the field data is green and the CWV assessment shows “passed,” the developer is right. If it shows “poor” or “needs improvement”, especially on INP, the Lighthouse score is not the right measurement to trust.
The distinction matters most when someone hands you a screenshot and says the speed problem is solved. Ask to see the field data, not the score. Those two sources tell you what Google sees because they are built from the same data Google uses.
A free assessment from iServU pulls your actual CrUX field data, your 75th-percentile LCP, INP, and CLS from real visitors on real devices, and maps it against Google’s published thresholds. Gabriel Lopez-Seco runs it directly. No account manager, no handoff.
Schedule a free assessment at iServU.
