Field Data vs Lab Data: Why Lighthouse and Real Users Disagree

You run Lighthouse and the report is red. Then you open PageSpeed Insights or Search Console and the Core Web Vitals say "Good". Or the other way round: the lab score looks healthy while real visitors still have a slow, jumpy page. Neither tool is broken. They measure different things.

This guide explains field data vs lab data in plain terms. Lab data is a single, controlled test. Field data is what real people experienced, collected from their browsers. You will learn where each kind comes from, why the numbers differ for each Core Web Vital, how to read both on one page, and which to act on first. It is for site owners, marketers and developers who have received conflicting performance reports and need to decide what to fix.

At the end you will be able to read a PageSpeed Insights report, explain a gap between the two kinds of result, and write a short, defensible plan.

Before you begin

You need one important URL to investigate, such as your home page or a high-traffic template, and access to PageSpeed Insights. If you have Google Search Console set up, open the Core Web Vitals report as well; see our Search Console setup guide if you have not verified your site yet. Chrome DevTools is useful for lab tests.

Be ready for a limit: field data is not available for every site. Google's documentation says the data comes from opted-in Chrome users, and pages and sites need enough visitors to appear. A new or low-traffic site may have no field data at all. That is normal, and it means lab data is your main tool for now.

Allow about an hour to compare one page properly.

What each kind of data is

Lab data comes from loading a page in a controlled environment. PageSpeed Insights describes it as a simulated load on a single device and a fixed set of network conditions. Lighthouse is the usual tool. It is repeatable, which makes it ideal for debugging and for testing changes before release. Lighthouse's performance score is a lab result: PageSpeed Insights groups scores of 90 and above as good, 50 to 89 as needing improvement, and below 50 as poor.

Field data is also called real-user monitoring. For most site owners it means the Chrome UX Report (CrUX), a public dataset of how real Chrome users experience websites around the world. Eligibility is not automatic. The Chrome documentation says origins and pages must be publicly discoverable and have enough visitors for statistically meaningful data. PageSpeed Insights shows CrUX results for the previous 28-day collection period and reports the 75th percentile of visits for each metric, so it reflects what most visitors had, not the average or the best case. Search Console's Core Web Vitals report also draws on CrUX data.

The pass marks for field data are the same Core Web Vitals thresholds that PageSpeed Insights and Search Console use: LCP is good at 2.5 seconds or less and poor above 4 seconds; INP is good at 200 milliseconds or less and poor above 500; CLS is good at 0.1 or less and poor above 0.25. The Core Web Vitals assessment passes when the 75th percentiles of all three are good (and when INP data is missing, when LCP and CLS are both good, per PageSpeed Insights documentation).

Step-by-step instructions

Step 1: Collect both results for the same URL

Enter the URL in PageSpeed Insights. Read the field section first (it is labelled as what real users experienced), then the lab section (the Lighthouse run). Switch between Mobile and Desktop. Search Console's report scores the two device types separately.

Note what you see for LCP, INP and CLS in the field, and the lab values for LCP, CLS and Total Blocking Time. Lab results do not include INP, because it needs real interaction.

What success looks like: You have a small table with field and lab values side by side for the same page and device type.

Step 2: Check what the field data covers

Field results can be at page level or origin level. PageSpeed Insights documentation says that when a page lacks enough samples it falls back to origin-level data, which covers all pages on the site. Search Console similarly groups URLs and falls back to a broader group when data is thin. Make sure you know which one you are looking at; an origin figure may be dominated by your busiest templates.

If there is no field data, the likely reasons in the PageSpeed Insights documentation are a recently published page, too few samples from opted-in users, or a URL that is not public and indexable. In that case rely on lab results and add your own real-user measurement later.

What success looks like: You can say whether the field figure is for the URL, a group or the whole origin.

Step 3: Compare metric by metric

Do not compare the overall Lighthouse score with a Core Web Vitals pass or fail. They are different questions. Compare the same metric in both places and ask how big and which way the gap is.

web.dev's comparison offers a useful example. In its LCP case, 88% of visits had an LCP of 2.5 seconds or less, 8% were between 2.5 and 4 seconds, and 4% were slower, with a 75th percentile of 1.8 seconds. A lab run of the same page gave 3.0 seconds. The article points out that the lab value is still valid; it is one value in a spread of experiences. That is the central idea: lab data gives you a point, and field data gives you a distribution.

What success looks like: For each of LCP, CLS and responsiveness you can write down whether lab is better, worse or close to field.

Step 4: Find the reason for any gap

web.dev lists many reasons the two kinds of data differ. These are the ones most useful in practice.

One device, one network, one place. A lab test uses a single device on a single network from a single location. Field data covers real devices, networks and geographies.
Cold cache. Lab tests start with an empty cache. For sites with good caching and many repeat visitors, web.dev says real-world LCP can be much faster than lab data suggests.
Back/forward cache. Pages restored from the back/forward cache load almost instantly and count in field data. Lab tests ignore them.
Different LCP elements. The lab picks the same element every run. In the field the element can vary with screen size, personalization, A/B tests and fonts. Also, the browser stops watching for larger elements after the user scrolls or interacts, which can make field LCP faster.
Responsiveness needs real interaction. Lab tools cannot predict when or how visitors interact, so Total Blocking Time is only a proxy for INP. web.dev notes that the tap delay on pages that are not mobile-optimized counts toward INP but not toward TBT, so a page can have good TBT and poor INP.
Layout shift over a longer period. Field CLS covers shifts across the whole life of the page, including after scrolling and interaction. Lab CLS only covers shifts during load. Ads, personalization and A/B tests can add shifts that a generic lab visitor never sees.
Slow first visits. Uncached images, iframes without dimensions and slow fonts cause more shifts on a first visit.

Check each possible cause against your own site. Do you have many returning visitors? Do you run experiments? Do you serve ads? These answers explain more than guessing.

What success looks like: Each gap in your table has a likely cause written beside it, such as "cached repeat visits" or "late ad slot".

Step 5: Decide which to act on

web.dev's advice is to use field data to prioritise your efforts, because it reflects what users experience. Use lab data to find further headroom when field results are good but lab results are poor, and to find users field data may miss. The article notes field data only covers users who are able to load your site, so lab tests on slow networks and low-end devices can reveal people who give up before they appear in the data.

A practical rule:

If field data fails a metric, work on that metric first, even if Lighthouse looks fine. Use lab tools to reproduce and debug it. See our guides for Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift.
If field data passes but lab fails, treat the lab result as a to-do list for improvement, not an emergency.
If there is no field data, use lab data as your guide and use repeated runs, because single runs vary.

What success looks like: You have a ranked list of fixes with a stated reason for each one.

Step 6: Re-measure on the right timescale

A fix you ship today will not show in field data today. The 28-day window in PageSpeed Insights and the rolling 28 days in Search Console mean old visits keep counting while new ones accumulate. Verify the fix in the lab straight away, then check field data after enough time has passed. Do not conclude too early that it failed.

To reduce regressions between checks, add automated lab tests to your build; see Lighthouse CI and performance budgets. Search Console's report uses URL groups and gives each group the status of its worst metric for a device type, so one weak metric can hold back a whole group.

What success looks like: You have noted a date after which you will review field data, and lab tests guard against new regressions in the meantime.

Final verification checklist

You compared field and lab values for the same URL and device type.
You know whether the field data is page-level, group-level or origin-level.
You compared LCP, CLS and responsiveness separately, not the overall score.
Every gap has a documented likely reason.
Fixes are prioritised by field results where field data exists.
You tested changes in the lab and set a date to review field data.
You tested on a throttled mobile profile as well as a fast desktop one.
Reports shared with others say which kind of data each number is.

Common mistakes to avoid

Treating the Lighthouse score as the Core Web Vitals result. The score is lab data. The pass or fail in field data uses 75th percentiles of real visits.
Expecting INP in the lab. Lab tools measure Total Blocking Time as a stand-in. Use field data for INP.
Ignoring field data because it is slow to change. It is slow because it covers a 28-day window. That does not make it less useful.
Chasing the lab score on a page that already passes in the field. You may spend time on something users do not feel. Look for real gaps first.
Comparing different device types. Mobile and desktop are scored separately. Compare like with like.
Reading origin data as page data. The fallback figure may describe your busiest pages, not the one you tested.
Expecting a ranking jump. Passing the thresholds is good for users. No tool or guide can promise a search result from it.

Frequently asked questions

Which is more accurate, field data or lab data?

They answer different questions. Field data shows what real visitors experienced across many devices. Lab data shows what one controlled test produced. web.dev suggests using field data to prioritise and lab data to debug and to look for headroom.

Why does PageSpeed Insights show no field data?

The usual reasons are a new page, too few samples, or a URL that is not public. The Chrome documentation also says origins and pages need enough visitors to produce statistically meaningful data. It is not a fault with your site.

Why is my lab LCP worse than field LCP?

Cold cache is one common reason. Lab tests start with nothing cached, while many real visitors have your files cached already or arrive through the back/forward cache. Different LCP elements and the way browsers stop watching after interaction can also produce faster field results.

Is CrUX the only source of field data?

No. CrUX is the public dataset that Google's tools use. You can also collect your own measurements from visitors' browsers, which can give you more detail on your own pages. Whichever you choose, label the source in reports.

Does Search Console use lab or field data?

Its Core Web Vitals report uses field data from CrUX, according to Google's help page, grouped by similar URLs and assessed per device type.

Official references

Next step: See how Crawvix checks a website and capture a baseline once scanning opens. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.