Why do your Core Web Vitals differ so much between lab and field?

What really sets lab data apart from field data?

Lab data pertains to tests conducted in a standardized environment — fixed connection, specific browser, reference device. This is what you get with Lighthouse or PageSpeed Insights in test mode. The environment is controlled and reproducible.

Field data, on the other hand, comes directly from the Chrome browsers of your real visitors. It reflects the brutal diversity of the field: a user on 4G in a rural area, another on degraded Wi-Fi, a third with a low-end smartphone that's 3 years old. It’s the Chrome User Experience Report (CrUX) that collects these metrics.

Why do these two sources yield such divergent results?

The main reason lies in the variability of real-world conditions. Your lab test may show an LCP of 1.8s on an emulated 4G connection, but your real users experience an LCP of 3.2s because they're browsing from poorly covered areas or using underperforming devices.

The second factor is the volume and diversity of data. A lab test captures a snapshot in fixed conditions. Field data aggregates thousands of sessions over 28 rolling days, with all possible variations of network, device, and browser cache. Outliers (the top 10% of users with the worst experience) pull the median down — and it’s precisely these users that Google considers for ranking.

What data source does Google use for ranking?

Google relies exclusively on field data (CrUX) to evaluate your Core Web Vitals for ranking purposes. Lab metrics are diagnostic tools, not ranking criteria. If your CrUX is green but your Lighthouse tests are mediocre, you can rest easy.

Conversely, a perfect lab score guarantees nothing if your real users are experiencing degraded performance. This is the classic trap: optimizing for the tool rather than for the user.

• Lab data: controlled tests, standardized environment, useful for diagnosis and rapid iterations
• Field data: real Chrome users, 28 rolling days, the only source used for Google ranking
• Discrepancies arise from variable connectivity and diversity of devices in real conditions
• Google focuses on the 75th percentile (the 25% of users having the worst experience) in CrUX
• A site may have excellent lab scores yet fail in field if its audience primarily uses low-end mobile devices

Is this distinction between lab and field really new for practitioners?

Let's be honest: any SEO who seriously works on performance already knows about this gap. It's not a revelation. Since the deployment of Core Web Vitals as a ranking signal, we know that CrUX is the standard. This reminder from Mueller mainly targets those who are new to the subject or who naively wonder why their great Lighthouse scores aren’t translating into positive field data.

The real issue is that this statement doesn’t say anything about the relative weight of CWV in the overall algorithm. Mueller confirms the mechanics, not the business impact. And that's frustrating — because we continue to see sites with catastrophic CWV performing well if their authority and content are strong.

What nuances should be added to this official explanation?

First of all, CrUX only covers sites with sufficient Chrome traffic. If you launch a site or if your audience is too small, you won't have any field data — and Google will then use origin or group page data. This creates a gray area for small sites or niches with little organic traffic.

Furthermore, field data is aggregated over 28 rolling days. If you fix a critical issue today, you'll have to wait about a month for the impact to reflect fully in CrUX. This delay frustrates clients who want immediate results. [To be checked]: Google has never publicly specified whether temporary traffic spikes (Black Friday, viral news) can distort CrUX metrics over time.

In what circumstances does this rule not apply or pose a problem?

The main problem concerns sites with a geographically or technologically heterogeneous audience. Imagine a French e-commerce site: your lab tests from Paris show flawless CWV, but 30% of your traffic comes from rural areas with poor connectivity, or from emerging countries with low-end devices. Your field data will be dragged down by this segment.

Another case: sites with dynamically or personalized content. A SaaS site with a heavy client-side dashboard may have acceptable lab metrics on the static homepage, but disastrous field data as soon as the user logs in. CrUX captures the overall experience, not just your marketing showcase.

What concrete actions should you take to reconcile lab and field?

First step: test on realistic devices and connections. Simulating a 4G connection on Chrome DevTools is good for starters, but it doesn't replace a real test on a mid-range smartphone with a real SIM card in a sparsely populated area. Invest in a few reference devices (an iPhone SE, a Samsung Galaxy A-series, an Xiaomi Redmi) and test regularly on them.

Second priority: segment your CrUX data. The Search Console provides an aggregated view, but the PageSpeed Insights API allows you to extract data by URL. Identify the pages that are hurting your field metrics — often, it’s a handful of templates or product pages with heavy scripts dragging everything down.

What mistakes should be avoided in optimizing Core Web Vitals?

The classic error: optimizing solely for Lighthouse. You can artificially inflate your lab score by disabling real features (analytics, chatbots, A/B testing) during tests. Result: a nice 95/100 in lab, but your real users are experiencing an LCP of 4s because the pop-up chat is blocking rendering.

Another trap: neglecting the 75th percentile. Google does not look at the median; it looks at the 25% of users having the worst experience. If your site is fast for 70% of visitors but terrible for the remaining 30% (slow mobile, rural areas), you fail in Google's eyes. Focus your efforts on this tail end of the distribution, not on the average.

How can you verify that your site genuinely passes the test under real conditions?

Use the Search Console as your source of truth, in the Core Web Vitals section. This is Google's official view of your field data, by group of URLs. If an entire category is in red, dig deeper: common template? Problematic third-party script? Unoptimized images?

Complement this with Real User Monitoring (RUM) tools like SpeedCurve, Cloudflare Web Analytics, or your own implementation via PerformanceObserver. You will have higher granularity than CrUX: segmentation by device, by country, by connection type. This allows you to detect that a CDN is underperforming in certain regions, or that a third-party script is causing massive layout shifts on Android only.

• Systematically test on real devices representative of your audience (entry-level and mid-range)
• Segment your CrUX data by URL group via the PageSpeed Insights API to identify problematic pages
• Never disable your real scripts (analytics, chat, A/B tests) during lab tests — measure the complete experience
• Focus your optimizations on the 75th percentile (the 25% slowest users), not on the median
• Implement Real User Monitoring to detect variations by geography, device, and connection
• Check the Search Console monthly (Core Web Vitals) to anticipate deteriorations before they impact ranking