Why Is My Lighthouse Score Different From Real User Core Web Vitals?

Lighthouse and real user monitoring disagree because they measure different things. Lighthouse runs one simulated visit on a fixed device and network with a cold cache. Real user monitoring reports the 75th percentile of actual shoppers across devices, networks and interactions. Use Lighthouse to diagnose a page, and use real user data to judge what shoppers experience.

Leadership opens Lighthouse, sees a respectable score, then opens a real user report and sees much slower numbers. Both are correct. They answer two different questions, and a store gets into trouble when it uses one to answer the other.

This guide explains why Lighthouse and real user Core Web Vitals differ, which one to trust for which decision, and how to explain the gap to a team that only looks at the lab score.

Why do Lighthouse and real user Core Web Vitals show different numbers?

Google's web.dev guidance on lab and field data describes the core difference: lab data comes from one controlled test, while field data is a distribution of numbers from real visits. A lab run is a single point, and the field number a tool reports is the 75th percentile of that distribution, so the two rarely line up exactly.

The practical effect is that neither number is wrong. In the web.dev example, 88% of visits had a good LCP of 2.5 seconds or less, and the 75th percentile LCP was 1.8 seconds, while the lab test for the same page showed 3.0 seconds. A lab score can look worse than the field, or better, depending on what the lab test leaves out.

What makes lab and field Core Web Vitals diverge on an online store?

Several factors explain most of the gap, and web.dev lists them. Each one is more pronounced on an ecommerce site than on a simple content page.

• Device and network mix. Lighthouse uses one emulated device. Real shoppers arrive on a spread of phones and connections, and mobile carries most ecommerce traffic.
• Cache state. Lab tests typically load a page cold. Returning shoppers often have resources cached, which can make real LCP and CLS better than the lab shows.
• User interaction. Lighthouse rarely scrolls or taps the way a shopper does, so it misses layout shifts that happen after interaction and the delay shoppers feel on add to cart.
• Personalization and experiments. Personalized content, A/B tests and different screen sizes can change which element is the largest on screen, so the LCP element can differ between the lab and real visits.
• The 28-day window. Google's field data from Chrome aggregates a 28-day period, so it lags recent changes that a lab run reflects immediately.

Which Core Web Vitals number should you trust?

Trust field data to decide whether shoppers have a speed problem, and use lab data to work out why a specific page is slow. Google rates a page as good when LCP is 2.5 seconds or less, INP is 200 milliseconds or less and CLS is 0.1 or less, measured at the 75th percentile of real visits. Those thresholds apply to field data, which is why a perfect lab score does not by itself mean the store passes.

INP shows why the lab cannot be the final word. Interaction to Next Paint depends on real taps and clicks, and a lab test cannot predict it. Total Blocking Time is a lab stand-in, but a page can show a good lab blocking time and still have a poor INP on a real phone.

For a store, the useful cut is field data grouped by page template and device: product, collection, cart and checkout, on mobile and desktop. A single sitewide score hides the template that carries the revenue. For the reasoning behind that grouping, see Core Web Vitals for ecommerce: which ones actually move conversion.

How do you explain the gap to leadership?

Show the two numbers side by side and label them. Lighthouse is a single test of one simulated visit, and the real user figure is what the slowest quarter of shoppers experienced. Saying the lab score is good and the field score is poor is not a contradiction. It means the page can load quickly under ideal conditions and still be slow for a meaningful share of real visits.

Then move the conversation to the pages that matter. A fast homepage in the lab says little about a product template on a mid-range phone over a mobile connection, and that template is usually where the revenue is.

Noibu's Performance Agent works from this field view. It measures Core Web Vitals from real shopper traffic, ranks the worst-performing page groups, finds root causes and stages changes for your approval, in the Noibu console or in AI tools your team already uses. Nothing ships until a person says so.

Frequently asked questions

What should you do next?

Pull your field Core Web Vitals by template and device, rank the failing ones by revenue, and use Lighthouse only to investigate the worst page. If you want to see your real user numbers by page without setting anything up, the free website audit from Noibu shows them. Noibu's Performance Agent then takes the ranked list and stages the changes for you to approve.

Noibu is AI for ecommerce operations, the always-on optimization system that keeps online stores running at their best. A team of supervised AI agents finds what's broken, slow, or leaking revenue, does the work, and hands results back for human approval. Trusted by retailers like Free People, Guess, Liquid I.V., and Ariat.

Related reading

• Noibu's Performance Agent
• Core Web Vitals for ecommerce: which ones actually move conversion
• How do I find which third-party scripts are slowing down my store?
• How to find slow pages hurting your ecommerce conversion
• web.dev: why lab and field data can be different

See your real user Core Web Vitals by page: run a free website audit →