There is a moment in every project where the developer says "the site is fast, I tested it" and the client says "it loads slow on my phone". Both are right. They are looking at different data.

Web performance has two main sources of measurement, lab data and field data, and they answer different questions. Confusing them produces the wrong fix.

Lab data: the controlled experiment

A lab test runs the site under known, controlled conditions. The classic example is Lighthouse: you open Chrome DevTools, click "Lighthouse", choose a device profile (Mobile, Desktop), and the tool simulates that device, throttles the network to a fixed bandwidth and latency, and measures how the page loads.

Other lab tools work the same way: PageSpeed Insights (which runs Lighthouse on Google's servers), WebPageTest, GTmetrix, Calibre.

The output is a list of metrics (LCP, INP, CLS, TBT, FCP, TTI) plus a score from 0 to 100. The score is a weighted average that Google updates from time to time. A score of 95 today does not mean the same thing as 95 in 2022.

What lab data is good for:

  • Comparing two versions of the same site under identical conditions. Did my optimisation help? Run before, run after, look at the delta.
  • Catching regressions during development. Run Lighthouse on every deploy, fail the build if the score drops more than X.
  • Diagnosing what is slow on a specific page. The waterfall view shows which resources block rendering.
  • Reproducing a problem reported by a user. With dev tools you can match their device profile and recreate the slowness.

What lab data is not good for:

  • Predicting what real users see. Your laptop is faster than 80% of phones. Your office connection is faster than 60% of mobile networks. Lab tests apply throttling, but throttling is not the same as a 4-year-old phone with junk in the cache.
  • Telling you whether Google considers your site fast for ranking. Google ranks based on field data, not lab data.
  • Measuring the impact of long-running interactions. A test that takes 30 seconds cannot capture how the page feels after 5 minutes of scrolling.

Field data: what real users see

Field data, also called RUM (Real User Monitoring), is collected from actual visitors using their actual devices, networks, locations, and browser states. It is messy, varied, and reflects reality.

The two main sources:

CrUX (Chrome User Experience Report): Google collects performance data from real Chrome users who opted in (which is most of them by default). The data is anonymised, aggregated by URL or by origin, and published. PageSpeed Insights shows it under "Origin Summary" or "URL Performance", expressed as the 75th percentile over the last 28 days. This is the dataset Google uses for Core Web Vitals as a ranking signal.

Self-hosted RUM: tools like SpeedCurve, Sentry, DataDog, Cloudflare Web Analytics install a small JavaScript snippet on your site that reports performance metrics for every page load to a collection endpoint. You get more granularity (segment by country, device, page, A/B group) but you pay for it.

What field data is good for:

  • Knowing whether real users are happy. The 75th percentile is the threshold Google uses; 75% of your users have an experience at least this good.
  • Catching problems that lab does not see: a third-party widget that loads slow only on Italian residential ISPs, a font that fails on iOS Safari 14, a server slow only at 9am on Mondays.
  • Understanding the distribution. The median user might be fine, the 90th percentile might be on fire. Lab gives you one number; field gives you a curve.

What field data is not good for:

  • Quick iteration. Field data updates over days or weeks. You cannot make a change and see the effect 30 seconds later.
  • Pages with low traffic. Field data needs enough samples to be statistically meaningful. A page that gets 50 views a month will show no field data in CrUX.
  • Diagnosing a specific cause. Field data tells you "5% of users have a slow LCP". It does not tell you why. For that you go back to lab.

How to use both

The healthy workflow alternates lab and field.

Field finds the problem: Search Console shows that LCP at the 75th percentile is 4.2 seconds. You have a problem.

Lab diagnoses it: you reproduce the slowness in DevTools with a 4G throttle and a Moto G4 profile. Lighthouse says the LCP element is the hero image, that the image is 2.3 MB, and that it is loaded from a CSS background.

You fix it: convert to AVIF at 220 KB, move from CSS background to a real <img> with fetchpriority="high".

Lab validates the fix: Lighthouse now shows LCP at 1.2s in the same conditions. Confidence the change is in the right direction.

Field confirms over time: in 7-10 days, field LCP at 75th percentile drops to 2.1s. The fix worked for real users, not just on your laptop.

If you skip field, you optimise things real users do not care about. If you skip lab, you optimise blind.

A common confusion: the score is not the metric

Lighthouse gives you a score (a number from 0 to 100, summarised as a coloured ring) and the underlying metrics (LCP in seconds, CLS as a fraction, etc.). People obsess over the score and ignore the metrics.

The score is a weighted average decided by Google. The weights change over time. The metrics are what matter for the user. A site can score 95 in lab and have a 4-second LCP in field, because the lab conditions are favourable and reality is not.

If you have to pick one number to track, track field LCP at 75th percentile, field INP at 75th percentile, field CLS at 75th percentile. Those are what Google uses for ranking. The Lighthouse score is for internal use, not for SEO.

Tools to actually open

If you do nothing else this week, open these three:

  1. PageSpeed Insights: paste your URL, scroll to "Origin Summary" or "URL Performance" if your traffic is enough. Read the field metrics.
  2. Search Console, Experience section. Same data, structured by URL group, with a history.
  3. Lighthouse in DevTools: pick the URL with the worst field LCP, run a lab test, look at the waterfall to find the cause.

The order matters. Field tells you whether you have a problem and where. Lab tells you why. Use both.