Why does Google overlook your Lighthouse scores when ranking your site?

What is the difference between field data and lab data?

Lab data comes from controlled simulations — typically Lighthouse in PageSpeed Insights, or tools like WebPageTest. These tests take place on a specific machine, a calibrated network, under perfectly reproducible conditions. Useful for diagnosing, but completely disconnected from reality.

Field data comes from the Chrome User Experience Report (CrUX). Google collects real metrics from actual Chrome users who visit your site. Variable network latency, heterogeneous devices, glitchy 3G connections — in short, real life. This is the source that Search Console displays in its Core Web Vitals report.

Why does Google prioritize CrUX data for ranking?

Simple: ranking aims to reward actual user experience, not a theoretical score obtained on an AWS server with dedicated fiber. A site can show 100/100 on Lighthouse and crash in production under load with poorly optimized third-party scripts. Google wants to measure what visitors endure, not what you showcase in a demo.

The CrUX aggregates data over a rolling 28 days, smoothing out momentary variations and reflecting a stable trend. It's this average that Google uses to determine whether your URLs meet the "Good" threshold for LCP, FID (or now INP) and CLS. No simulation, just concrete results.

Are lab data really useless?

They are still essential for diagnosing. Lighthouse tells you *why* your LCP is poor — unoptimized image, render-blocking CSS, slow server. But once the problem is identified and fixed, it's the CrUX that will validate (or not) that your real users benefit from the improvement.

Many practitioners fall into the trap: they optimize until they achieve a perfect lab score, then are puzzled when ranking doesn't budge. It's normal — the ranking signal doesn't read Lighthouse, it reads CrUX. If your traffic primarily comes from unstable 4G mobiles, your field data will remain mediocre even with impeccable lab data.

• Field data (CrUX): real data collected from Chrome users, aggregated over 28 days, the only source considered for the Core Web Vitals ranking.
• Lab data (Lighthouse): reproducible simulations, useful for diagnosis and identifying technical optimizations, but ignored by the ranking algorithm.
• Ranking threshold: a URL must reach the "Good" threshold in CrUX (75th percentile) to benefit from the Core Web Vitals boost — the lab score has no direct impact.
• Propagation delay: any technical improvement takes up to 28 days to fully reflect in CrUX, and thus in the ranking signal.
• Minimum traffic: for a URL to have field data, it must receive a sufficient volume of Chrome visits — otherwise, Google uses data at the origin level (entire domain).

Is this statement consistent with observed practices in the field?

Absolutely. The audits I've conducted over the years show a nearly zero correlation between Lighthouse score and organic traffic evolution. I've seen sites jump from 40 to 95 in lab without any ranking impact, and others stagnate at 60 but explode in visibility after correcting their field data. CrUX is the final arbiter.

The problem is that many agencies still sell "Core Web Vitals optimizations" based on Lighthouse. They deliver a pretty green report, the client applauds, and three months later, traffic hasn't budged. Why? Because they optimized for a synthetic test, not for real users — who navigate on a Xiaomi over 3G in the Paris metro.

What nuances should be added to this claim by Google?

Google remains intentionally vague about the granularity of the signal. We know that CrUX aggregates at the URL level if the volume is sufficient, otherwise it switches to the origin level. But what is this traffic threshold? A mystery. [To be checked]: no official data on the minimum number of Chrome visits needed to trigger a URL-level evaluation.

Another gray area: the relative weight of the Core Web Vitals signal in the overall algorithm. Google repeats that it is "one signal among others," which in practice means that for ultra-competitive queries, mediocre content with a perfect CrUX will never overturn a solid competitor with an average CrUX. The boost exists, but it’s not magic — and Google will never publish its exact weighting coefficient.

In what cases does this rule not really apply?

If your site has not enough Chrome traffic to generate field data, Google has nothing to evaluate. In this case, either it uses data at the origin level (which dilutes the performance of your best pages), or it simply overlooks the signal. Small sites and very fresh pages are in this gray area.

Second limiting case: bots and crawlers. Googlebot does not contribute to CrUX — it does not measure user experience in the strict sense. So if your site is technically fast but your third-party scripts (analytics, chat, ads) sabotage the real experience, Googlebot won't see anything during the crawl, but the CrUX will bury you. And it's the CrUX that wins.

What should you do concretely to optimize the ranking signal?

Stop chasing Lighthouse scores and focus on the Core Web Vitals report in Search Console. This is where you see what Google sees: the CrUX data aggregated by group of URLs. If a URL is ranked "Poor" in this report, it receives no boost — regardless of its lab score.

Identify the real bottlenecks: poor LCP? Look at the images, server TTFB, blocking fonts. Unstable CLS? Track ads shifting content, embeds without dimensions. High INP? Your third-party scripts are likely to blame. Lighthouse gives you clues, but always validate the improvement in CrUX before claiming victory.

What mistakes should be absolutely avoided?

First classic mistake: optimizing only for desktop while 70% of your traffic comes from mobile. The CrUX separates data by device type, and Google uses the mobile version for ranking (mobile-first indexing). A site that shines on desktop but struggles on mobile loses the signal.

Second pitfall: ignoring third-party scripts. No matter how well you optimize your images and CSS, if Google Tag Manager loads 15 trackers synchronously, or if your live chat blocks the main thread for 800 ms, your INP skyrockets. And Lighthouse in the lab won’t always see this — but the CrUX will. Audit your third-party scripts critically, and defer anything that's not critical above the fold.

How can I check if my site is compliant and that optimizations are yielding results?

Monitor the Core Web Vitals report in Search Console every week. Google updates this data daily, with a rolling window of 28 days. If you deploy an optimization today, expect to see a gradual impact over 3-4 weeks — the time it takes for the new data to replace the old in the aggregate.

Complement this with PageSpeed Insights on your strategic URLs: check the section "Discover what your real users encounter" (field data). If it says "No data available," it means the URL doesn’t have enough Chrome traffic — Google will then use data at the origin level. In this case, improving an isolated page won’t help; you need to address the site as a whole.

• Install RUM (Real User Monitoring) to track Core Web Vitals in real time, independently of CrUX — tools like Cloudflare Web Analytics, SpeedCurve, or Sentry can detect regressions before they pollute your Google data.
• Segment your CrUX data by device type (mobile/desktop/tablet) and by connection (4G/3G/slow-2G) to identify user populations pulling your score down.
• Implement performance budgets for third-party scripts: no more than X KB of external JS, no more than Y ms of blocking time — and enforce these limits by your product and marketing team.
• Test your pages on real devices (not just DevTools mode) with throttled connections — a Moto G4 on 3G reveals problems that Lighthouse in the lab will never see.
• Automate post-deployment audits: every release should trigger a Lighthouse test + a check of field data on a sample of URLs — to detect regressions before they impact CrUX.
• Document the correlations between CrUX improvements and organic traffic evolution: this will help you quantify the real ROI of Core Web Vitals optimizations and adjust your priorities accordingly.