# Lab data vs field data: Lighthouse, CrUX and Core Web Vitals > Lab data is one simulated Lighthouse load; field data is real visits over 28 days. See how they differ and why a page can pass one but fail the other. Published: 2026-11-15 ยท Author: AiroPages Lab data is what a test like Lighthouse measures on one simulated device during one page load. Field data is what real Chrome users experienced on their own devices, collected in the Chrome UX Report (CrUX) and reported at the 75th percentile over a rolling 28 days. Google assesses Core Web Vitals on field data, but you fix problems using lab data, so you need to understand both. ## The short version The two kinds of data answer different questions: - **Lab data answers "why?"** It is repeatable, available for any URL, and comes with audits that point at specific files and scripts. You can test a fix in minutes. - **Field data answers "does it matter?"** It reflects your actual audience, their phones, networks and behavior, and it is the basis for the [Core Web Vitals](/glossary/core-web-vitals) assessment. Neither is more "correct". They measure different things, which is why they often disagree. ## What lab data is Lab data comes from a synthetic test run in a controlled environment. Lighthouse is the most common source. It loads one URL, emulates a mid-range phone (or a desktop), applies simulated throttling to model a slow 4G connection and a slower CPU, and records what happens from the first request until the page settles. That gives you: - **Lab metrics:** Largest Contentful Paint, Cumulative Layout Shift, Total Blocking Time, First Contentful Paint and Speed Index. - **A performance score** from 0 to 100, calculated from those five metrics. - **Audits and insights** that explain what to change, such as render-blocking requests or oversized images. Lab data is available for any page you can load, including new pages with no traffic, staging sites and pages behind a login (if you test from DevTools or the CLI). Its weakness is that it is one visit, on one device profile, with no real user. ## What field data is Field data, also called real-user monitoring (RUM) data, is collected from actual visits. Google's public source is the [Chrome UX Report (CrUX)](/glossary/crux), built from Chrome users who have opted in to sharing usage statistics. It is what PageSpeed Insights shows in its field data section and what Google Search Console's Core Web Vitals report is based on. Three details define how CrUX reports data. ### The 75th percentile CrUX reports the 75th percentile of each metric, not the average. That means 75% of visits were at or better than the reported value, and 25% were worse. If your 75th percentile LCP is 2.3 seconds, three out of four visits saw the main content within 2.3 seconds. Google uses this point so that a page only passes when most visitors have a good experience, not just the ones on fast phones and fiber connections. ### The rolling 28-day window CrUX aggregates visits over the previous 28 days, and the window moves forward continuously. A fix you ship today starts to improve the numbers as new visits replace old ones, but the reported value only fully reflects the fix after about four weeks. ### Enough traffic CrUX only includes pages and origins with enough real Chrome traffic. Popular URLs get their own page-level data. Less visited URLs may fall back to origin-level data, which covers the whole site. Many pages, especially new or niche ones, have no field data at all. Mobile and desktop visits are reported separately. ## Lab data vs field data at a glance | | Lab data (Lighthouse) | Field data (CrUX) | |---|---|---| | Source | One simulated page load | Real Chrome users | | Device and network | Fixed test profile | Whatever visitors actually use | | Time period | The moment you run it | Rolling 28 days | | How results are reported | Single values from one run | 75th percentile of all visits | | LCP and CLS | Yes (CLS during page load only) | Yes (CLS across the whole visit) | | INP | No | Yes | | Total Blocking Time | Yes | No | | Available for any URL | Yes | Only with enough traffic | | Used for Core Web Vitals assessment | No | Yes | | Best for | Diagnosing and testing fixes | Confirming real-user impact | ## INP is field-only, and TBT stands in for it [Interaction to Next Paint (INP)](/glossary/inp) measures how quickly a page responds to clicks, taps and key presses throughout a visit, and reports one of the slowest interactions. It replaced First Input Delay as a Core Web Vital in March 2024. A good INP is 200 ms or less, and anything over 500 ms is poor. A standard Lighthouse run loads the page without interacting with it, so it cannot measure INP. Instead, Lighthouse reports [Total Blocking Time (TBT)](/glossary/tbt): the total time long tasks blocked the main thread during load. A blocked main thread is the most common reason interactions feel slow, so a high TBT is a strong hint that INP may suffer in the field. TBT is a proxy, not a match. A page with a low TBT can still have poor INP if a specific interaction, such as opening a filter menu or adding an item to a cart, runs heavy JavaScript after the page has loaded. Our guide to [INP and slow interactions](/blog/inp-explained-fix-slow-interactions) covers how to find those. ## Why a page can pass in the lab and fail in the field Passing Lighthouse does not guarantee passing Core Web Vitals. Common reasons: - **Slower real devices.** If much of your audience uses low-end phones, their experience can be worse than the test profile. - **Real interactions.** INP depends on what users click. A lab test never opens your mega menu or product configurator. - **Layout shifts after load.** Lighthouse measures CLS during load. In the field, CLS covers the whole visit, including shifts from lazy-loaded ads, infinite scroll or late banners. - **Content the test did not see.** Consent banners, logged-in views, personalization, A/B variants and geo-targeted content may be heavier for real users. - **Distance from your server.** Visitors far from your hosting or CDN wait longer for every request. For example, a news article might score 90 in the lab, but real readers scroll down, ads load into slots with no reserved space, and the field CLS fails. ## Why a page can fail in the lab and pass in the field The reverse is common too, and it confuses people who only watch the Lighthouse score. - **Faster real devices.** The mobile test applies a 4 times CPU slowdown on a mid-range phone profile. If most visitors use recent phones, real loads are faster. - **Caching and repeat visits.** Lighthouse tests a cold load. Real visitors often have your CSS, fonts and scripts cached already. - **Back/forward navigations.** Pages restored instantly from the browser's back/forward cache count as very fast real visits. - **Your audience's networks.** Many visitors are on Wi-Fi or fast mobile connections, not slow 4G. A lab failure is still worth fixing in these cases. It shows where the page would struggle for the slowest visitors, and those visitors are the 25% above your 75th percentile. ## How to use lab and field data together A simple workflow keeps both in their place: 1. **Start with field data** in PageSpeed Insights or the Search Console Core Web Vitals report. Find which metric fails, on which device, for which group of pages. 2. **Reproduce it in the lab.** Run Lighthouse on representative URLs from the failing group and read the audits behind the failing metric. 3. **Fix and verify in the lab.** Change one thing, re-run, and compare the metrics with the same settings. 4. **Confirm in the field.** Watch the field data over the following weeks as the 28-day window rolls forward. If a page has no field data, rely on lab results and treat them as an early warning. For more on how the two tools fit together, see [Lighthouse vs PageSpeed Insights](/blog/lighthouse-vs-pagespeed-insights). ## How to check this across your whole site Field data problems are usually reported for groups of URLs, while lab tests run one URL at a time, which is the gap we describe in [Lighthouse only tests one page](/blog/lighthouse-only-tests-one-page). The manual way to close it is to export the URL groups from Search Console, run Lighthouse on a sample from each group, and query the CrUX API for each URL to see which ones have page-level data. AiroPages does this in one scan: it runs Lighthouse on every page on mobile and desktop and shows Chrome UX Report field data next to the lab scores wherever Google has it. Issues are grouped by template, so you can match a failing field metric to the template fix that addresses it. ## Two views of the same page Lab data and field data are two views of the same page: one controlled and immediate, the other real and slow to change. Use Lighthouse to understand and fix problems, use CrUX to see whether real visitors and Google's Core Web Vitals assessment agree, and expect them to differ for good reasons.