Why Does Field Data for Site Speed Differ from Lab Tests?

A tool score of 100, and a user who calls the site "slow"

You open PageSpeed Insights, see a green score of 98 or 100, and still get calls from clients saying "your site won't load." Or you access it yourself from home on mobile data and the page really is heavy. This contradiction isn't a bug in the tool; you're mixing two different worlds of measurement: Lab Data and Field Data.

Tools like Lighthouse and PageSpeed Insights load a page from a headless browser on a specific server with a fast, stable internet connection. The result is a score. But your user in Shiraz on 4G mobile data, a mid-range phone, and during peak hours has a completely different experience. Field data measures exactly that real experience. This article is about that difference and why you should trust field data, not a score obtained in a vacuum.

What is lab data and where does it mislead

Lab data is measurement in a controlled environment. Lighthouse runs a Chromium browser on a virtual machine with fixed specifications, simulates the network (throttling), and calculates metrics like LCP and CLS. This method is excellent for finding technical issues like heavy JavaScript or images without dimensions. But it has a fundamental limitation: a simulated network is not a real network.

Lighthouse's Mobile simulation applies a latency of about 150 milliseconds and a bandwidth of 1.6 Mbps. These numbers are derived from averages of real networks from previous years. But your user might be in an area with 300ms latency, or conversely, on fiber optic with 5ms latency. The result is that your lab score is an estimate, not a reality.

The bigger problem is hardware. The Lighthouse lab device is a virtual machine with an average processor. Your user's phone might be an expensive flagship or an affordable budget device. The difference in processing power between the two can change JavaScript execution time by up to 5 times. Field data shows this difference; lab data never will.

Here's where they go wrong: mistaking a green score for a good experience

The most common mistake I've seen in support work is this: a site manager tests a page with PageSpeed Insights, gets a score of 95, and reports the result to the CEO. A week later, the bounce rate goes up and no one understands why. When you open the CrUX report, you see that the real user LCP is 4.8 seconds, while the lab test shows 1.8 seconds. That 3-second difference is exactly where users leave the site.

What's the sign of this mistake? A page that's green in the tool but has a bounce rate above 70% in the Analytics report. Or a comment from a user saying "your site won't open on my phone" while you tested on desktop. If you see these signs, look at field data first, not the page code.

CrUX field data: the only reliable source

Field data is collected from real users' browsers. Google anonymously collects this data from the Chrome browser of users who have opened your page and publishes it in a collection called the Chrome User Experience Report (CrUX). This data includes Core Web Vitals metrics: LCP, INP, and CLS. Important note: this data only exists for pages that have sufficient traffic.

The CrUX publication threshold is typically around 20 unique visits per day for a URL. If your site is newly launched or has low traffic, CrUX won't have data for it. In this case, PageSpeed Insights shows the "Field Data" section as empty and only displays lab data. This doesn't mean the site is good; it just means not enough data has been collected yet.

There are two ways to view field data. First, the PageSpeed Insights page, which automatically shows CrUX. Second, the official CrUX website on Google BigQuery, which provides raw data for deeper analysis. Using BigQuery requires SQL knowledge, but for a quick check, PageSpeed Insights is sufficient.

How to correctly read field data

CrUX presents data as a percentile. The number Google reports is the 75th percentile. That means 75% of your users had a better experience than this number, and 25% had a worse one. This number is important because the average can be misleading. If 90% of your users have an LCP under 2 seconds and 10% have over 10 seconds, the average would be around 3 seconds, which doesn't look bad. But the 75th percentile gives a more accurate picture of the majority experience.

Remember Google's thresholds for Core Web Vitals: LCP should be under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. If your CrUX is in the "Needs Improvement" range, meaning between the good and poor thresholds, you should take action. If it's in the "Poor" range, users are genuinely leaving your site.

Why field data and lab data differ

The difference between these two types of data is natural and isn't always a sign of a problem. But when the gap widens, you need to find the reason. Three main factors create this difference:

• Real network: Lighthouse uses a fixed network profile, but your users are on various networks with different qualities. Home Wi-Fi, mobile data, or corporate networks each have different latency and bandwidth.
• Device hardware: Budget phones have weaker processors, and JavaScript execution is slower for them. This difference can significantly impact INP.
• External factors: Your server might respond more slowly during peak hours. Or your CDN might not perform well in a specific region. Lab data doesn't see these fluctuations.

An important point: if the difference between field and lab data is less than 20%, it's usually not a serious issue. But if your field data is double your lab data, you have an infrastructure or coding problem that isn't visible in lab tests.

Practical approach: where to start

The first step is to check your own site's field data. Open the PageSpeed Insights page and look at the "Field Data" section. If there's no data, your traffic is low. In this case, you should rely on lab data but with the awareness that it may differ from reality.

If field data is available and in poor condition, follow this order:

1. First, check LCP. This metric usually has the most significant impact on user experience. If LCP is above 2.5 seconds, look for the page's hero element and optimize it. The practical guide Improving LCP can be a good starting point.
2. Then, check INP. If it's above 200 milliseconds, the problem is your JavaScript. Heavy event listeners or long JavaScript execution on the main thread are the main culprits.
3. Finally, check CLS. If it's above 0.1, the problem is elements that shift after the initial load. Images without dimensions, late-loading fonts, and animated ads are the most common causes. Read the article Fixing CLS layout shifts for more details.

An important note: optimizing for field data differs from optimizing for lab data. In lab data, you can raise the score by removing JavaScript or reducing image sizes. But in field data, you need to pay attention to factors like server response time (TTFB) and network quality. If your server is in Iran and you have users abroad, your TTFB will be high, and no client-side optimization will solve this. In this case, using a CDN or intermediary servers is essential.

For a more detailed check of your domain's and DNS's technical status, you can use domain technical check tools. DNS latency can add a few tenths of a second to TTFB, which shows up in field data but not in lab data.

Here's where they go wrong: optimizing for the score, not the user

I've often seen developers do strange things to raise their Lighthouse score. For example, they load images at very small dimensions and then scale them up with CSS. The LCP score improves, but the image is blurry for the user. Or they split page content into several sections and only load the first part to register a faster LCP. These actions raise the tool's score but ruin the user experience.

What's the sign of this mistake? Your field data is good (LCP under 2.5 seconds), but the conversion rate is low. Or users spend little time on the page. If you see these signs, you've probably optimized for the score, not the user. Field data only shows speed, not content quality or overall experience. A fast page with poor content will still drive users away.

Images and fonts: two hidden factors in field data

Images and fonts are two factors that are hard to see in lab data but have a significant impact on field data. An image that's 200KB in a lab test might become 300KB on a real network due to carrier compression. Or a font loaded from an external server might face high latency in Iran.

For images, be sure to use modern formats like WebP and AVIF. These formats reduce size by up to 30% without noticeable quality loss. Read the practical guide Image optimization with WebP and AVIF. For fonts, host Persian fonts on your own server and use asynchronous loading. External fonts like Google Fonts load with high latency in Iran and can worsen CLS.

Another point: if you use a content management system like WordPress, caching and optimization plugins can help, but not always. Some plugins inject extra code into the page that worsens INP. Before installing any plugin, check its impact on field data, not just the lab score.

Complementary tools for analyzing field data

CrUX isn't the only source of field data. Several other tools can provide a more complete picture:

• Google Search Console: The Core Web Vitals report in Search Console separates field data by device type (mobile and desktop) and lists problematic pages. This report is the best option for finding specific pages with issues.
• Web Vitals JavaScript Library: You can add this library to your own site to collect field data in real-time from your users. This data is more accurate than CrUX because it includes all your users, not just Chrome users.
• RUM (Real User Monitoring): Tools like New Relic or Datadog collect field data with more detail, including geographic information, browser type, and connection type. These tools are paid but worth investing in for large sites.

If your site is WordPress-based, there are also lightweight RUM plugins that collect data automatically. But be careful: the RUM plugin itself adds JavaScript and can worsen INP. A lightweight library like web-vitals, which is under 1KB, is a better choice.

Final decision: which one should you rely on?

My clear answer: Field data. If your CrUX has data, make it the primary basis for decision-making. Lab data is only useful for finding the root cause of a problem, not for measuring success. If your CrUX has no data (low-traffic site), use lab data but with the awareness that it might be optimistic.

There's one exception: if your site is newly launched and doesn't yet have enough traffic for CrUX, lab data is your only option. In this case, focus on definitive optimizations like reducing image sizes, compressing code, and using browser caching. These actions have a positive impact on both types of data.

And if your site has good traffic but CrUX shows no data for it, the problem is in how data is collected. Make sure your site is served over HTTPS and you have no JavaScript errors in the browser console. CrUX only collects data for HTTPS pages.

Finally, remember that speed optimization isn't a one-time project. Your field data fluctuates with changing seasons, user behavior, and Google's algorithm updates. Have a regular schedule (e.g., monthly) to review field data and compare it with lab data. If you see a discrepancy, investigate. If not, you're doing things right.

If you need expert help analyzing field data and optimizing your site's speed, our SEO services team can perform a complete technical and content audit of your site and provide an action plan to improve Core Web Vitals.

Frequently Asked Questions

What is CrUX field data and where does it come from?

CrUX is a dataset that Google collects from real users' Chrome browsers. This data includes LCP, INP, and CLS metrics and is anonymously recorded from users who have opened your page. To view it, open your site's PageSpeed Insights page and look at the Field Data section.

Why doesn't my PageSpeed Insights show field data?

Field data only exists for pages with sufficient traffic, typically around 20 unique visits per day. If your site is newly launched or has low traffic, CrUX won't have data for it. In this case, PageSpeed Insights only shows lab data.

Does a score of 100 in PageSpeed Insights mean a fast site?

No. A score of 100 only indicates that the page performed well in the Lighthouse lab environment. Field data can be completely different, especially if your users are on mobile networks or weaker devices. To be sure, always check CrUX field data.

How can I improve my site's field data?

First, check your CrUX and see which metric (LCP, INP, or CLS) is in the poor range. Then focus on that metric. For LCP, optimize images and the server. For INP, reduce JavaScript. For CLS, specify image dimensions and fonts. Read the complete guide on Core Web Vitals.