Payments are experiencing issues due to temporary restrictions in Russia. If your payment does not go through, please submit a support request.Our support team is available 24/7 — we are always here to help with hosting and server issues.We are now accepting requests for dedicated server rental and colocation services in our data center.Reminder: we recommend enabling backups for additional data protection.A new VPS/VDS lineup with NVMe storage and improved performance is now available.Maintenance work on some servers has been completed. All services are operating normally.
Article5 min readViews0

Lighthouse scores 90+, but Core Web Vitals fail: why it happens

I explain why a green lab score can differ from field metrics, how to compare like-for-like conditions, and how to find the cause without guesswork.

АльбинаCommunity author★ 145
Comments 0

Two ways to measure website speed: a controlled test and a variety of real devices
In this article

PageSpeed Insights can present an encouraging picture: the Lighthouse lab result is green and scores 90 or more, while the section above says the Core Web Vitals assessment has failed. There is no need to start changing everything at once. These parts of the report answer different questions.

The key distinction is this: Lighthouse shows a single synthetic run under specified conditions and combines several lab metrics into an overall score. Core Web Vitals in the field section of PageSpeed Insights describe the distribution of real visits over a rolling 28-day period and are assessed at the 75th percentile. A green lab score does not invalidate the slow experience of some visitors — and the reverse is also true.

First, identify which number you are comparing

In its PageSpeed Insights documentation, Google separates the report into Lighthouse lab data and field data from the Chrome User Experience Report, or CrUX. Their sources, reporting periods, and the meaning of the results differ.

  • Performance 90–100 is the overall Lighthouse lab score. It is calculated as a weighted combination of several metrics from one simulated run.

  • Field LCP, INP, and CLS are aggregated data from real Chrome users. When sufficient data is available for all three metrics, their values must meet the recommended thresholds at the 75th percentile to pass the assessment. If INP data is insufficient, PageSpeed Insights assesses LCP and CLS. If LCP or CLS data is insufficient, the assessment is unavailable.

  • The field section may cover the exact URL or the whole origin. These levels must not be silently treated as the same page.

A single lab run compared with a distribution of field data over 28 days
The lab records a single predefined scenario; field data covers a variety of real devices and shows a distribution.

The overall score's composition and metric weights are described in the Lighthouse documentation. This establishes an important distinction: a score of 90+ is not a fourth Core Web Vitals metric and does not certify passing results for LCP, INP, and CLS.

Why lab and field data differ

Lab testing deliberately reduces the number of variables: one device profile, one network scenario, one geographic location, and one page load. This is useful for diagnosis and comparing changes. Real visitors, however, arrive with different phones, networks, caches, login states, and behaviour.

In its explanation of the differences between lab and field data, Google makes clear that a discrepancy does not in itself indicate an error in the report. A field value is a point in a distribution of many visits, while a lab value represents one observed scenario.

The metrics themselves also differ. Lighthouse uses Total Blocking Time as a lab indicator of responsiveness, whereas field Core Web Vitals include INP, which requires real interactions. Lab CLS may miss a shift that occurs several seconds after loading or after a user action. And LCP from one run does not have to match the 75th percentile over 28 days.

Worked example: why a majority of fast visits may not be enough

Imagine 100 visits to one page. In this sample, 74 visits have an LCP of 2.0 seconds and 26 have an LCP of 3.2 seconds. If the values are sorted in ascending order, the 75th observation already falls into the 3.2-second group. The 75th percentile therefore misses the good threshold of 2.5 seconds, even though almost three quarters of visits were fast.

An illustrative distribution of one hundred visits: 74 with an LCP of 2.0 seconds and 26 with an LCP of 3.2 seconds
In this sample, the 75th observation is 3.2 seconds, so p75 exceeds the good LCP threshold of 2.5 seconds.

This is a simplified model, not a recalculation of a particular CrUX report: real tools aggregate far more observations and apply their own processing to the distribution. But this is how selecting the 75th percentile distinguishes fast for a majority from fast for roughly three in four or more. The method is described in the Core Web Vitals thresholds documentation.

How to find the cause without arguing with the numbers

  1. Record the data source: field CrUX or lab Lighthouse, the exact URL or origin, mobile or desktop, the dates of the 28-day period, and the time of the lab run.

  2. Compare corresponding metrics: LCP with LCP and CLS with CLS. Do not equate INP with TBT: the lab metric helps identify main-thread blocking, but does not reproduce the distribution of real interactions.

  3. Repeat the lab run several times with identical settings and save not only the overall score, but also the metric values, the environment, and the identified LCP element. One successful run is a useful clue, but weak evidence of consistency.

  4. Find out exactly who experiences slow performance: mobile users, users of a particular template, logged-in users, people in a particular geographic area, or visitors to pages with a large catalogue. If you collect your own RUM data, segment it using the same conditions.

  5. Fix the confirmed mechanism. A large LCP image, a late banner, a long JavaScript task, and a server queue require different actions; the overall score does not choose a solution for you.

If the problem occurs only under load, a separate VPS resource calculation for a store may help. It does not replace field Web Vitals, but helps examine the server side of the scenario without conflating it with the visitor's device and network.

When a conclusion is justified

The difference between Lighthouse and field data becomes useful once you formulate a testable hypothesis. For example: mobile visits to product pages are worsening field LCP, while the lab run tested the home page with a different device profile. You then need the same set of URLs, the same form factor, a recorded reporting period, and observations after a specific change.

Field data takes time to reflect changes: PageSpeed Insights shows a rolling window covering the previous 28 days, so a fix today may not be fully reflected in tomorrow's metric. Lab testing, by contrast, can show the effect immediately, but only within its own scenario.

I would start by asking which audience and period each number describes, rather than which number to trust. Lighthouse is useful for reproducible diagnosis. Field data shows the distribution of real experiences. A solution emerges when the URL, device, metric, and cause align — without promising that a single green score will automatically improve search rankings.

GENERAL IT

Help with your project

SEO services

Improve site structure and content around relevant search demand.

GENERAL IT

Read more on this topic

Discussion 0

Share your experience and ask questions. Comments without links appear after editorial review.

No comments yet. Start the discussion.