Why don't your Lighthouse scores truly reflect your site's real performance?

What’s the fundamental difference between Lab data and Field data?

Lab data comes from tools like Lighthouse that test your site under controlled conditions. Powerful machine, recent CPU, fiber connection, cleared cache, no ad blockers, no browser extensions. In short, an ideal environment that 99% of your real visitors will never experience.

Field data (CrUX) collects performance metrics from real Chrome users who have opted in to share statistics. Mid-range Android phones costing €200, congested 3G connections in the subway, variable network latency, overheated processors because 12 tabs are open—that's the reality.

Why can these two measurements diverge so much?

A site can score 95 on Lighthouse and be in the red on CrUX. The gap comes from three main factors: hardware power (an iPhone 13 vs a budget Android from 2019), network quality (1Gb/s fiber vs 3G with 2 signal bars), and geolocation (CDN optimized for Paris but a single server in Virginia for the rest of the world).

The classic trap? Optimizing your site on your MacBook Pro connected via ethernet, validating with a Lighthouse score of 98, and discovering three months later that 60% of mobile traffic in Sub-Saharan Africa or Southeast Asia suffers from an LCP of 8 seconds. Field data reveals these blind spots.

Which metrics does Google prioritize for ranking?

Martin Splitt is clear: Field data is a better indicator of real user experience. For Core Web Vitals used as a ranking factor, Google relies on CrUX—not Lighthouse. If your CrUX is non-existent (site too new or insufficient traffic), Google may use other signals, but the goal remains to capture the on-the-ground experience.

In practical terms? A perfect Lighthouse score guarantees nothing for SEO if your real users suffer from poor performance. Conversely, a site with an average Lighthouse score but excellent Field data maintains a competitive edge. It's the perceived performance that matters, not laboratory performance.

• Lab data (Lighthouse): controlled synthetic environment, useful for detecting technical issues and tracking trends
• Field data (CrUX): real user experience, the only metric considered for ranking via Core Web Vitals
• Frequent divergences: a good Lab score does not imply good Field performance (and vice versa)
• Gap factors: hardware (CPU/GPU), network (latency, bandwidth), geolocation (distance to server/CDN)
• Priority action: consult CrUX as a priority (Search Console, PageSpeed Insights, BigQuery), use Lighthouse as a supplementary diagnostic tool

Is this distinction actually applied by Google?

Yes, and it's observable. Sites that have prioritized switching from Lab metrics to Field metrics find that the Core Web Vitals rankings in Search Console never perfectly match Lighthouse scores. We often see pages marked "Good" in CrUX with a Lighthouse score of 70, and "Needs Improvement" pages despite a Lighthouse score of 90.

The problem is that many mainstream SEO tools still display Lighthouse scores as the primary reference, creating a false impression of performance. Clients see a nice green 95 and don't understand why Search Console shows orange. This distinction needs to be explained consistently.

What are the limitations of CrUX data?

CrUX is not without biases. It only collects data from Chrome users (desktop and mobile) who have enabled sync and statistics sharing—about 60-70% of total Chrome traffic, which itself represents ~65% of the market. Safari, Firefox, and Edge users (outside of the old Chromium) do not show up in CrUX.

Another limitation: the minimum traffic threshold. If a page receives fewer than a few hundred visits over 28 days, it won't appear in CrUX. For niche sites or new pages, you can be without Field data for weeks or even months. [To be verified]: Google has never publicly communicated the exact threshold, but empirical testing suggests ~500-1000 visits/month minimum.

Should you completely ignore Lighthouse?

No, and that would be a mistake. Lighthouse remains the most comprehensive diagnostic tool for identifying technical problems: blocking JavaScript, unoptimized images, absence of HTTP cache, unused CSS. It’s a medical scanner—it detects pathologies but does not measure daily quality of life.

The right approach? Use Lighthouse to audit and fix, then validate the real impact on CrUX 4-6 weeks later (the time required to collect Field data). If your Lighthouse score improves but CrUX stagnates, dig deeper into CrUX segments by connection type (4G, 3G, slow-2G) and by device (mobile vs desktop)—you'll often find that a specific population is dragging the average down.

How can I access the Field data for my site?

Three main channels. First, Google Search Console (Core Web Vitals section): this is the clearest view for an SEO, with grouping by status (Good, Needs Improvement, Poor) and by page type. Limitation: data is aggregated by groups of similar URLs, no URL-by-URL granularity except in specific cases.

Next, PageSpeed Insights: enter a URL, and if it has Field data, you'll see the CrUX metrics (LCP, FID/INP, CLS) for the last 28 days. Advantage: you can test any public URL. Disadvantage: if the URL lacks traffic, you'll only get Lab data (Lighthouse).

Finally, CrUX via BigQuery (free): a public dataset updated monthly. You can query data by origin (full domain) or by specific URL if it has sufficient traffic. This is the most powerful method for analyzing segments (connection, device, geo), but it requires SQL skills.

What should I do if my Lab and Field data diverge significantly?

Segment CrUX data by dimension: connection (4G, 3G, 2G/slow), device (mobile, desktop, tablet), and if possible geolocation. You often find that a specific segment is dragging the average down—for example, 3G users in India or Sub-Saharan Africa if your CDN has no local PoPs.

On the technical side, check for third-party resources (analytics, ad pixels, live chat, social widgets). Lighthouse often ignores them in simulated mode, but in real conditions, a poorly optimized third-party script can add 2-3 seconds to LCP or trigger massive layout shifts. Use WebPageTest with a 3G mobile profile to recreate Field conditions.

If you find that mobiles are performing badly but desktops are acceptable, focus on image weight and JavaScript execution. Mobile CPUs are 5 to 10 times slower than a modern desktop—an 500KB JS bundle that parses in 200ms on your Mac will take 2 seconds on a mid-range Android.

What mistakes should I avoid when optimizing for Field data?

Don't base your optimization solely on your development environment. Testing on a MacBook Pro with fiber won’t tell you much. Use real mid-range devices (Android ~€200-300, 2-3 years old) and simulate degraded connections (3G, 200ms+ latency). Chrome DevTools allows you to throttle CPU and network—make use of it.

Another trap: optimizing for Lighthouse at the expense of real user experience. A classic example is aggressive lazy-loading that defers all images, even above-the-fold. Lighthouse loves it (fewer initial requests), but in the Field, LCP blows up because the hero image loads too late. Or similarly, inlining all critical CSS to eliminate render-blocking—your Lighthouse score goes up, but now the HTML weighs 150KB and the Time to First Byte increases.

Lastly, do not neglect visual stability (CLS). Field data captures layout shifts during the entire browsing session, including those caused by user behavior (quick scroll, tap during loading). A carousel that shifts on load, ad inserts with no reserved dimensions, web fonts causing FOIT/FOUT—all of this devastates CLS in real conditions even if Lighthouse doesn’t always detect it.

• Review Search Console > Core Web Vitals at least weekly to monitor Field trends
• Use PageSpeed Insights as a priority to evaluate individual URLs (Field data + Lab suggestions)
• Segment CrUX data by connection and device to identify problematic populations
• Test on real mid-range mobile devices with simulated 3G connections
• Ensure that Lighthouse optimizations do not negatively impact real user experience (watch out for aggressive lazy-loading, excessive inline CSS)
• Monitor third-party resources (analytics, ads, chat) that often weigh more heavily in the Field than in the Lab