Why don't your Lighthouse tests reflect your real Core Web Vitals scores?

What is the difference between field data and lab data?

Lab data comes from tools like Lighthouse, PageSpeed Insights, or WebPageTest that simulate a page load under standardized conditions: fixed network, defined processor, no cache, disabled extensions. It's reproducible, useful for diagnosing issues, but completely disconnected from what your users experience.

Field data is collected via the Chrome User Experience Report (CrUX): millions of Chrome browsers send their real metrics — LCP, FID, CLS — during authentic browsing sessions. Unstable 3G connections, low-end devices, active extensions, multitasking: everything that impacts the real experience is captured. This is the data Google uses for the ranking signal.

Why does Google prioritize field data for ranking?

Because SEO aims to measure the quality of the real user experience, not the theoretical performance of a server. A site might load in 0.8 seconds on fiber with a MacBook Pro, while it could take 6 seconds on a mid-range smartphone with fluctuating 4G.

Google needs to know what your visitors are really experiencing to assess if your page deserves a boost or a penalty. Field data captures network conditions, geographical distribution, device types — everything that a local Lighthouse test completely ignores.

How is field data collected and aggregated?

CrUX aggregates metrics by origin (entire domain) and by URL (individual pages) over a rolling window of 28 days. Only URLs with sufficient Chrome traffic appear in the dataset — confidential pages or those with very few visitors often lack usable field data.

Google then calculates the 75th percentile: if 75% of your visitors have an LCP under 2.5 seconds, your score turns green. If only 60% meet this threshold, you're in orange or red. This is a measure of experience consistency, not maximum performance.

• Lab data is useful for diagnosing and reproducing problems, but it does not directly influence ranking.
• CrUX field data is the only source used by Google for the Core Web Vitals ranking factor.
• A perfect lab score guarantees nothing if your real users experience poor performance.
• URLs without significant Chrome traffic lack CrUX data — they inherit the score at the origin level.
• The 75th percentile is the decisive threshold: 75% of your visitors must meet the thresholds to achieve a "good" status.

Is this statement consistent with field observations?

Yes, and it is indeed one of the few positions from Google that perfectly aligns with what is observed in production. Websites that score 100/100 on Lighthouse but have predominantly low-end mobile traffic gain no SEO advantage if their CrUX is in the orange zone.

Conversely, sites with average Lighthouse scores (60-80) but a favorable field distribution — users on fiber, desktop, well-utilized cache — can easily exceed CrUX thresholds and benefit from the positive signal. The problem is that many SEOs continue to optimize for local audits instead of analyzing real CrUX data via PageSpeed Insights or Search Console.

What nuances should be added to this claim?

Google says "entirely based on field data," but this deserves an important clarification: if a URL has no CrUX data (insufficient traffic, no Chrome visitors, protected content), Google reverts to origin-level data. If the entire origin lacks data, no CWV signal is applied — neither bonus nor penalty.

Another nuance: lab data remains essential for diagnosing. When your CrUX turns red, it's Lighthouse that helps you identify the blocking third-party script, the unoptimized image, or the culprits behind layout shifts. Both sources are complementary: the lab for understanding, the field for measuring SEO impact.

In what cases does this rule not fully apply?

Websites with predominantly non-Chrome traffic (Safari, Firefox) or specific audiences — webview mobile apps, corporate environments with modified browsers — may have a biased or incomplete CrUX sample. In these cases, the Core Web Vitals signal is either absent or not representative.

Pages with soft 404, redirects, or server errors do not accumulate usable CrUX data. Sites entirely behind authentication or paywalls often have no public data — Google cannot measure what it cannot see. [To be verified]: it is unclear whether Google uses anonymized CrUX data from authenticated sessions to refine the signal, but nothing in the official documentation confirms this.

What actionable steps should be taken to optimize for field data?

First, stop using Lighthouse as the sole reference. Focus on the real CrUX data available through PageSpeed Insights ("Field data" tab), Search Console (Core Web Vitals report), or the CrUX API directly. These sources show you the real 75th percentile, by device type (mobile/desktop), and changes over 28 days.

Next, segment your analysis: if your traffic is 80% mobile, optimize first for real mobile conditions — slow networks, limited CPUs, narrow viewports. A site that performs well on desktop but fails on mid-range mobile will lose its CWV signal despite impeccable lab scores.

What mistakes should be avoided when optimizing Core Web Vitals?

Do not over-optimize for a test environment that does not reflect your audience. If you're testing on fiber from Paris with a MacBook and 70% of your visitors are in West Africa on 3G, your lab optimizations will be pointless. Use network and CPU throttling tools, but better: test on real representative devices.

Another trap: ignoring seasonal or event-based variations. An e-commerce site that sees a spike in traffic at Christmas will change its user mix — more mobile users, more unstable connections. If your infrastructure doesn’t scale, your CrUX will plummet exactly when you have the most traffic. Field data is unforgiving: it captures reality, not your intentions.

How can I verify that my site is compliant and maintain the level?

Set up a continuous CrUX monitoring: use the CrUX API via BigQuery, Looker Studio dashboards, or third-party solutions that track daily developments. The rolling window of 28 days means that a degradation can take up to a month to appear in reports — and another month to disappear after correction.

Establish automatic alerts if the 75th percentile drifts towards orange/red thresholds. Test every major deployment in production with Real User Monitoring (RUM) before it impacts the official CrUX. And most importantly, document the correlations between infrastructure/code changes and the evolution of field metrics — it’s the only way to manage based on facts.

• Check PageSpeed Insights "Field data" tab and Search Console Core Web Vitals report every week.
• Segment analysis by device type (mobile/desktop) and prioritize based on actual traffic distribution.
• Test on real mid-range devices with network throttling representative of the target audience.
• Continuously monitor the 75th percentile CrUX via API or dedicated dashboards to anticipate deviations.
• Audit third-party scripts and blocking resources that negatively impact LCP and FID under real conditions.
• Document each deployment with its measured impact on field metrics to build a reliable history.