Short answer
Field data comes from real Chrome users over the previous 28 days and decides whether a page passes Core Web Vitals. Lab data comes from one simulated load on a single device and network setting, and is best for diagnosing causes and testing fixes. When they disagree, the field data describes what visitors experienced.
Two kinds of measurement
Field data, sometimes called real-user monitoring, is collected from actual visits. Lab data is collected by a tool that loads the page under controlled settings. PageSpeed Insights shows both, and Google explains the difference directly: real-user data in PSI "is powered by the Chrome User Experience Report (CrUX) dataset", while the lab data "is based on a simulated load of a page on a single device and fixed set of network conditions" [1].
Field data in detail
CrUX is described by Google as "a dataset that reflects how real-world Chrome users experience popular destinations on the web" [2]. In PageSpeed Insights it covers "the previous 28-day collection period" [1]. Three details are worth knowing.
- Not every page or site has it. CrUX includes pages and origins that are publicly discoverable and "sufficiently popular". Google does not publish the threshold [3]. Smaller sites often see field data for the whole origin but not for individual pages, or none at all.
- Not every visitor is counted. Users must have opted into usage statistics and history sync, and the platforms covered are desktop Chrome and Chrome on Android. Chrome on iOS is excluded [3]. If many of your visitors use iPhones, CrUX describes only part of your audience.
- It moves slowly. Because the window is 28 days, a fix released today takes about four weeks to be fully reflected.
Lab data in detail
Lab data comes from Lighthouse: Google says PSI "uses Lighthouse to analyze the given URL in a simulated environment" [1]. The familiar 0 to 100 performance score is built from five weighted metrics. Chrome's documentation lists the Lighthouse 10 weights as Total Blocking Time 30%, Largest Contentful Paint 25%, Cumulative Layout Shift 25%, First Contentful Paint 10% and Speed Index 10% [4]. PageSpeed Insights treats 90 or above as good, 50 to 89 as needing improvement and below 50 as poor [1].
Two points often surprise people. First, the lab score does not include Interaction to Next Paint, because a lab run has no real visitor to interact with; Total Blocking Time stands in as a related measure. Second, scores vary between runs. Chrome's documentation says "a lot of the variability in your overall Performance score and metric values is not due to Lighthouse" [4]. Network conditions, server load and browser extensions all play a part.
Why the two disagree
| Reason | Effect |
|---|---|
| Real devices vary | Field data mixes fast and slow phones; the lab uses one simulated device |
| Cached visits | Returning visitors load faster than the lab's cold, uncached run |
| Interactions | Field INP reflects real clicks and taps; the lab cannot measure INP |
| Different pages | Field data may be for the whole origin; the lab tests one URL |
| Time window | Field data covers 28 days; the lab is one moment |
Which one should you act on?
Use field data to decide whether there is a problem and which metric and device type it affects. It is what Google uses for the Core Web Vitals assessment, and Search Console's report is built on it [5]. Use lab data to find the cause and to check that a fix works, because it responds immediately and lets you compare like with like.
When the lab score looks good but field data fails, trust the field data and look at what the lab does not see: slow interactions after the page has loaded, real device speeds, and third-party scripts that only load for some visitors. When the lab score looks poor but field data passes, your visitors are probably doing better than the simulation suggests. You can still improve the lab score, but it is not urgent.
Getting more realistic lab results
Chrome DevTools lets you throttle the CPU to approximate "the typical performance of low- and mid-tier mobile devices" and to set custom network profiles [6]. Testing with throttling on gives a better feel for what a quarter of your visitors experience. We also recommend testing the same few templates each time, under the same settings, and running each test more than once.
When there is no field data
If CrUX has no data for your site, Search Console will show "No data available", which is common for new properties [5]. In that case, lab testing under realistic mobile settings is the best guide you have. Be careful not to present lab numbers as real-user results to anyone, and revisit the field data as traffic grows.
Origin data versus page data
PageSpeed Insights can show two kinds of field data: data for the specific URL you tested and data for the whole origin, meaning all pages on the domain combined. When a page does not have enough visits on its own, you may only see the origin view. That is still useful, but it blends fast and slow templates together. A slow product page can hide behind a fast home page, or the reverse. Search Console's grouping of similar URLs sits between the two and is often the most practical view for deciding what to fix [5].
A worked comparison
Imagine a fictional article page. The lab test shows LCP of 3.4 seconds and a performance score of 61, which looks poor. The field data shows LCP of 2.2 seconds at the 75th percentile, which passes. Why the difference? The lab simulates a first visit on a slower device and network with nothing cached [1]. Many real visitors are returning readers whose browsers already hold the fonts and styles, and many use faster devices than the simulation. In this case, the page is fine for most visitors, and the lab result is a useful warning about first-time visitors on slower phones rather than an emergency.
Now reverse it. The lab score is 92, but field INP is 340 milliseconds and failing. The lab cannot click anything, so it never saw the slow menu that opens after a tap. Here the field data is telling you about a real problem the lab cannot measure, and the fix will involve testing interactions by hand with a throttled CPU [6].
Keeping lab tests comparable
Because lab results vary, the comparison only means something when the conditions match. Test the same URLs, in the same tool, with the same throttling settings, at a similar time of day, and run each test several times. Record the median rather than the best run. Close browser extensions or use a clean profile, since extensions can add work to every page. Chrome's documentation is clear that a lot of score variability comes from outside Lighthouse itself [4], so controlling what you can makes before and after comparisons more trustworthy.
Adding your own field data
CrUX is free and convenient, but it has blind spots: it needs enough traffic, it leaves out Chrome on iOS, and it only reports at the level of URLs and origins [3]. Sites that need more detail can collect their own real-user measurements with a small script that records Core Web Vitals in visitors' browsers and sends them to an analytics tool. That shows which interactions are slow, which pages and devices are affected, and how changes land within days rather than weeks. It also adds a script to every page, so it is worth doing only when the extra detail will be used.
Questions about field and lab data
Why does my score change every time I run PageSpeed Insights?
Lab tests are affected by network conditions, server load and other factors on each run. Run the test a few times and look at the underlying metrics rather than a single score.
Why is there no INP in the lab section?
INP needs a real person interacting with the page. Lab tools use Total Blocking Time as a related measure, but only field data can show INP.
How long after a fix will field data improve?
PageSpeed Insights field data covers the previous 28 days, so improvements appear gradually and are fully reflected after about four weeks.
Sources
Opened and checked on November 3, 2026.
- About PageSpeed Insights, Google for Developers. Primary documentation, last updated October 21, 2024.
- Overview of CrUX, Chrome for Developers. Primary documentation, last updated February 8, 2024.
- CrUX methodology, Chrome for Developers. Primary documentation, last updated June 20, 2024.
- Lighthouse performance scoring, Chrome for Developers. Primary documentation, last updated September 19, 2019.
- Core Web Vitals report, Search Console Help. Primary documentation, checked November 3, 2026.
- Throttling, Chrome DevTools documentation. Primary documentation, last updated April 16, 2024.