Understanding this difference saves a great deal of wasted work. Website owners sometimes fix a problem that exists only in the test while ignoring one their visitors experience every day. This guide explains what each type of data measures, why they differ and how to use both to decide what to fix first.
Two Numbers Answering Different Questions
Lab data is the result of a single controlled load of a page. According to PageSpeed Insights documentation, the test uses Lighthouse to simulate loading on a midrange mobile device over a cellular network, or a desktop computer with a wired connection. It answers: what happens when this page loads under these conditions, right now?
Field data, also called real-user data, is something quite different. In PageSpeed Insights, it comes from the Chrome User Experience Report, CrUX, and summarizes what real Chrome users experienced over the past 28 days. It answers: how did this site feel to people who actually visited it?
This difference also determines how the data is used. Anyone wanting to learn how to read the report in depth, section by section, can find guides to measuring website performance in Hebrew, including explanations of PageSpeed Insights reports and LCP, INP and CLS. Here we will focus on one question: why the two numbers are separate, and what to do about it.
Why the Lab Does Not See What Users See
In Philip Walton's article on web.dev, which examines differences between lab and field data, he explains that a lab test runs on one device, one network and from one geographic region. Your visitors, by contrast, arrive with new and old phones, fiber connections and weak mobile networks, from anywhere in the world.
Caching creates another difference. A lab test generally loads the page with an empty cache, as though it were the first visit ever. A returning visitor already has some files in the browser, and someone pressing the Back button may receive the page almost immediately from browser memory. Field data can therefore be better than lab data, not just worse.
For illustration only, such a gap might mean that a site whose visitors mostly return daily looks slow in the lab and fast in the field. A news site whose traffic mostly comes from older phones on mobile networks may look good in the lab and fail in the field.
The Three Metrics and What Each Misses in a Test
LCP measures when the largest element in the visible portion of the page is displayed. According to web.dev, that element in the lab is not necessarily the same one users see. A different screen size, personalized content or a font loading differently can change it. In the field, measurement stops when the user scrolls or clicks, so the result also depends on behavior.
INP measures how quickly the page responds to clicks, taps and typing. Here the gap is greatest: a lab cannot know when a real user will click or on what, so INP is not truly measured there. Instead, the report includes Total Blocking Time, intended to help diagnose responsiveness problems. But web.dev warns that a page may have good TBT and still deliver poor INP for users.
CLS measures how much content shifts while a visitor reads. In the lab, only shifts during loading and near the top of the screen are counted. In the field, shifts after scrolling or clicking also count, for example when an ad loads in the middle of an article. A page that looks completely stable in a test can therefore jump around for real readers.
The 75th Percentile: Why an Average Is Not Enough
Field data is not one number but a distribution of thousands of visits. To summarize it, PageSpeed Insights displays the 75th percentile for each metric. This means the number describes the experience of most visitors, including some who had a less comfortable experience, rather than just the average.
According to PageSpeed Insights documentation, the good-result thresholds are up to 2.5 seconds for LCP, up to 200 milliseconds for INP and up to 0.1 for CLS. To pass the Core Web Vitals assessment, the 75th percentile must meet the threshold for all three.
For illustration only, if a quarter of a site's visits come from weak devices and load slowly, they can alone pull the result below the threshold, even if every test on your office computer looks excellent. In other words, field data is a reminder that the website was not built for your computer.
What to Do When There Is No Field Data
Not every page has field data. When a particular page lacks enough visits, PageSpeed Insights displays data for the whole site, or origin, covering all its pages together. If the entire site also lacks enough data, the real-user section simply does not appear.
This is common on small sites, new pages and sites with few Chrome visitors. In that case, lab data is the main remaining tool and should be used carefully: run the test several times, check both mobile and desktop modes, and remember that it estimates one set of test conditions rather than measuring your users. Anyone wanting a real picture can add their own measurement to the site, collecting metrics directly from visitors.
How to Use Both Together
The recommendation on web.dev is clear: field data determines what is important to fix, while lab data helps explain why the problem occurs and how to test a fix. If field data shows poor INP, lab testing can help find heavy scripts blocking the browser, even if it does not measure INP itself.
Distinguish between what is measured and what is expected too. After a fix, the lab score changes immediately, providing a useful indication that the change worked under test conditions. Field data, however, summarizes 28 days, so the improvement, if users actually feel it, takes time to appear fully. A lab change is an expectation. A field change is a result.
Another useful rule: do not chase a score of 100. Lighthouse's performance score is a diagnostic tool, not the goal. A page can score perfectly in the lab and still feel slow for some users, while a page with a middling score can pass the field Core Web Vitals assessment.
The Takeaway
The two numbers in the report are not a contradiction but two pieces of evidence: one from a controlled experiment and one from the field. Website owners who understand the difference know not to panic over a low lab score when users are satisfied, or relax over a high score when field data fails. It is the same principle described in the article on website backups and recovery plans: what matters is what happens in reality, not what is supposed to happen.
No measurement guarantees rankings, traffic or sales. But a site measured correctly is one where you know what to improve, and working hours go toward problems visitors actually feel.
More articles in the Internet section.
