Your PageSpeed score says 96. A customer emails to say the site feels slow on her phone. Both are telling the truth. They are measuring different things. Web performance data comes in two kinds, lab and field, and most of the confusion around PageSpeed scores comes from treating one as if it were the other.
This post explains what each kind actually measures, why the two routinely disagree about the same page, what the four Core Web Vitals metrics mean in plain English, and which number Google actually uses.
Lab data: one controlled run
Lab data comes from a tool, usually Lighthouse, loading your page under fixed conditions: an emulated mid-range phone, a throttled network, a clean cache, one location. The famous 0 to 100 PageSpeed score is a lab number. Because the conditions never change, the result is reproducible. Run it twice and you get roughly the same answer.
That reproducibility is the point. Lab data is a diagnostic. Change something, run it again, and the difference you see is the difference you made. It also comes with a breakdown: which image is oversized, which script blocks rendering, which request chain delays the main content. When you are debugging performance, lab data is the tool that tells you where to cut.
What lab data is not is a measurement of anyone's actual experience. Nobody visits your site on an emulated phone from a test datacentre with an empty cache. One synthetic visit, however carefully staged, is still one visit under one set of conditions.
Field data: what visitors actually experienced
Field data is collected from real visits: real devices, real networks, real cache states, measured in the browser while actual people use the page. Instead of one number from one run, you get a distribution across thousands of visits, and the convention is to report the 75th percentile, the value that three quarters of visits did better than. The p75 convention stops a fast median from hiding a slow tail.
Field data is also what Google uses. The Chrome UX Report (CrUX) collects field measurements from opted-in Chrome users, and it is CrUX field data at the 75th percentile, not your Lighthouse score, that feeds the page experience signal in ranking. A site can score 55 in the lab and pass Core Web Vitals in the field, and vice versa.
Why the two disagree
Lab and field results for the same page routinely differ, for boring structural reasons rather than measurement error.
- Device mix. The lab emulates one mid-range phone. Your audience might be mostly recent iPhones on fast connections, or mostly five-year-old Androids. Either way, the emulated device represents almost none of them.
- Cache states. A lab run is always a cold first visit. Real traffic is a blend of first visits and repeat visits with warm caches, and repeat visits are much faster. A site with loyal returning visitors will look better in the field than in the lab.
- Geography. The lab tests from one place. Your visitors are spread across networks and distances, and the ones far from your server experience latencies no single test run reproduces.
- Third-party variance. Ad tags, chat widgets, fonts and analytics vary from load to load. A lab run samples that variance once. The field records its full spread, including the bad days.
So a good lab score with poor field numbers is normal, and so is the reverse. Neither result is wrong. They answer different questions.
The four metrics in plain English
Both kinds of data report the same underlying metrics. Each has a "Good" threshold, applied at the 75th percentile in the field.
| Metric | What it measures | Good |
|---|---|---|
| LCP (Largest Contentful Paint) | How long until the main content of the page is visible. | 2.5 s or under |
| INP (Interaction to Next Paint) | How long the page takes to respond when a visitor taps, clicks or types. | 200 ms or under |
| CLS (Cumulative Layout Shift) | How much the layout jumps around while the page loads. | 0.1 or under |
| TTFB (Time to First Byte) | How long the server takes to start answering at all. | 800 ms or under |
TTFB is not a Core Web Vital itself, but it sits underneath the others: a slow first byte puts a floor under how fast anything else can be.
When to use which
Use field data to decide whether you have a problem. It is the ground truth about what visitors experience, and it is the number that matters for ranking. Use lab data to find out why and to check a fix. Field data says "mobile LCP is 4.1 seconds at p75"; a lab run then shows you the oversized hero image causing it, and a second lab run confirms the fix before the field numbers catch up over the following weeks.
The mistake to avoid is optimising the lab score for its own sake. A change that lifts the score but does not move the field numbers has improved a simulation.
How TLDTrack measures both
TLDTrack collects both kinds, and it is worth being precise about where each comes from. The lab side is a scheduled Lighthouse-based check that runs weekly against your monitored pages, giving a consistent, comparable score over time and an alert when it drops. The field side comes from your own visitors, not from CrUX: install the tracking snippet and TLDTrack measures LCP, INP, CLS and TTFB from real visits, reports them at the 75th percentile over the last 30 days, and splits mobile from desktop, because the two rarely tell the same story. Your own field data will not exactly match CrUX either, since CrUX samples only opted-in Chrome visitors and needs enough traffic to publish at all, while your snippet measures the visitors you actually have. The same snippet also powers heatmaps and visitor analytics, so one tag covers both jobs. The full detail of both checks is on the PageSpeed monitoring page.
