⚡ Web performance

Lab data and field data: why the scores do not match

Lighthouse and field data measure different things: how to read both, why they diverge, and which one to rely on when deciding where to work on your site.

One of the questions I get most often is: «Lighthouse gives me 95, but the Core Web Vitals report says the pages are slow. Who is right?». Both are, because they measure different things. Understanding the difference between lab data and field data saves weeks of work in the wrong direction.

What lab data is

A lab test loads the page once, under controlled conditions: a simulated device, a CPU slowed down by a certain factor, a network with fixed bandwidth and latency, an empty cache. Tools such as Lighthouse, the DevTools Performance panel or synthetic testing services belong to this family.

The advantages are clear:

  • repeatability: the same conditions let you compare a change with the previous version;
  • diagnosis: you get the request waterfall, main-thread traces, suggestions;
  • immediate availability: you can test a page nobody has visited yet, even in a staging environment.

The limit is that this single simulated visit does not represent any particular real user.

What field data is

Field data, also called RUM (Real User Monitoring), is collected from the browsers of the people who actually visit the site. There are two main sources: the Chrome User Experience Report, which anonymously aggregates data from Chrome users who have opted in and feeds search engine reports, and your own collection via a script on the page.

Field data reflects real variety: old and new phones, home Wi-Fi and mobile networks on the move, full or empty caches, visitors arriving from an ad or returning for the tenth time. The value that counts for Core Web Vitals is the 75th percentile: it means three visits out of four must be at least that fast.

Why the numbers diverge

The typical reasons lab and field tell different stories:

  1. Devices: Lighthouse's mobile profile simulates a mid-range phone; the real audience may have much slower or much faster devices.
  2. Cache: the lab almost always starts with an empty cache; many real users come back and find CSS, fonts and scripts already cached.
  3. Interactions: INP requires real interactions. A test that just loads the page touches nothing, so in the lab you can at most use Total Blocking Time as an indirect indicator.
  4. Visit length: field CLS includes shifts during scrolling and after load, which the initial test does not see.
  5. Different pages: the field report often groups similar URLs; the test measures a single address.
  6. Personalized content: consent banners, logged-in users and A/B test variants change the page compared with the one the tool sees.

Which to use, and when

The rule I follow is simple: field data tells you whether there is a problem, lab data helps you understand why.

Question Source
Do users have a good experience? Field
Which metric is out of bounds? Field
Which resource slows down LCP? Lab
Did this change improve things? Lab, then confirm in the field
Which page or template is worst? Field, segmented by URL

A Lighthouse score of 100 is not a goal in itself: it is a weighted summary of lab metrics. Optimizing for the number while ignoring real data sometimes leads to cosmetic changes that do not move people's experience.

Making the lab more realistic

You can bring the test closer to reality:

  • set CPU throttling according to the most common devices in your audience, which you can find in your analytics;
  • also test with a warm cache, by reloading the page a second time;
  • run several repetitions and look at the median, because a single test can vary considerably;
  • test pages in their real state, with the consent banner visible and, if needed, as a logged-in user.

The delay in field data

There is one last difference to keep in mind. The aggregated data of the Chrome User Experience Report is based on a rolling 28-day window: after a fix, the improvement appears gradually over a few weeks. Those who collect their own RUM data instead see the effect almost immediately, which is one of the reasons it is worth doing.

In short

  • Lab tests are repeatable and diagnostic; field data represents real users.
  • They diverge because of devices, cache, interactions, visit length and personalization.
  • The field tells you whether there is a problem, the lab helps you find the cause.
  • The Lighthouse score is a summary, not the final goal.
  • Aggregated data reacts over weeks; your own RUM shows the effect of changes right away.
MM
Marco Marzaduri

Marco Marzaduri works in cybersecurity, digital forensics and web development. A computer science graduate, he combines rigorous technical analysis with attention to the people who use technology.

Read also