Lab vs Field

The problem

Every other experiment gave you a number: “load time 1.6 s”. It’s one number, for one device, on one connection, on one visit. A real site doesn’t have a load time. It has a distribution of them: a lot of fast visits, some slow ones, and a long tail of very slow ones.

That’s why a page can score 95 in Lighthouse and still be miserable for a quarter of its visitors. Neither number is wrong. They answer different questions: lab data answers “what happens under these exact conditions?”, field data answers “what happens to the people who actually visit?”.

Things to try

1. “The developer’s world”. Mostly desktops on fast connections with a warm cache. The page looks fine, the laptop line sits well inside “good”, and you’d ship it.
2. “A mobile-first, emerging-market audience”. Same page, same code. The distribution slides right, and the 75th percentile fails. The lab lines didn’t move at all.
3. Compare the median to the 95th percentile. The worst one visit in twenty is many times slower than the typical one.
4. Switch the metric to INP, then tick “Ship half the JavaScript”. Look at which row of the audience table gained the most.
5. Switch to CLS. Most visits have no shift at all, so the median is zero. The problem is entirely in the tail.
6. Apply every fix to the emerging-market audience, and see how far it gets. Then compare it with the “developer’s world” with no fixes.

How the field is judged

• The 75th percentile. Three in four visits are at least this good. Core Web Vitals check the 75th percentile of each metric, not the average, because the average hides the slow visits the metric is there to protect.
• Three thresholds. LCP: good up to 2.5 s, poor above 4 s. INP: good up to 200 ms, poor above 500 ms. CLS: good up to 0.1, poor above 0.25. A page passes when each metric’s 75th percentile is good.
• Where the data comes from. The Chrome UX Report collects it from real Chrome users who’ve opted in, over a rolling 28 days. PageSpeed Insights shows that field data at the top, and a Lighthouse lab run below it.
• Your own measurement. The web-vitals library reports each metric from the visitor’s browser, so you can segment by device, country and page:

import { onLCP, onINP, onCLS } from 'web-vitals';

function send(metric) {
  navigator.sendBeacon('/vitals', JSON.stringify({ name: metric.name, value: metric.value, id: metric.id }));
}
onLCP(send);
onINP(send);
onCLS(send);

sendBeacon is used because the final values are often only known when the visitor leaves the page.

Why the lab and the field differ

Who is being measured

Lighthouse is one synthetic visitor on a fixed device profile. The field is everyone, including the low-end phones, slow connections and cold caches you didn’t think of.

What happens after load

A lab run loads the page and stops. Real people scroll, tap and stay. INP and CLS are measured across the whole visit, and a lab run sees only the start. This is why Lighthouse reports Total Blocking Time as a lab stand-in for INP.

Variation

The same lab run, repeated, gives slightly different numbers. The field’s variation is enormous, and that spread is the information.

State

Lab runs are usually logged-out, uncached and without ads, consent banners or personalisation. Real visits are not.

Use both, for different jobs. Field data tells you whether you have a problem and for whom. Lab data lets you reproduce it and test a fix, because it’s repeatable and you can control it. A good workflow: find the worst segment in the field, recreate that device and network in the lab, fix it, then confirm in the field, which takes a few weeks to show up.

Common misconceptions

Don’t memorise rules. Understand the system.

Twelve experiments, one idea. Each technique here exists because of something the browser does: it can only request what it has discovered, it has one main thread, it can’t paint without the CSS, a cache only helps if the files stay unchanged. Once you know the mechanism, the advice stops being a checklist. You can tell when a technique applies, what it costs, and how to check it worked.

Measure before optimising. Then measure the people who actually use your site.

See it on a real site

1. Enter your URL in PageSpeed Insights. Read the field-data section first. Does the page pass? Which metric fails? Then compare it with the lab score underneath.
2. Add the web-vitals library to the site and send the values to your analytics, with the device type and connection.
3. In DevTools, set CPU throttling and network throttling to match your worst common visitor, not your best, and reproduce the problem there.
4. After a fix, wait for the 28-day field window to turn over before declaring victory.

Model assumptions