Your Lighthouse Score Is 95 and Your Users Still Complain the Site Is Slow — Lab Data, Field Data, and Why They Diverge

Core Web Vitals lab data and field data measure the same page but can tell completely different stories — a page that scores 95 in Lighthouse measures from an idealised simulated environment, while the same page might score 45 in the Chrome User Experience Report (CrUX), which aggregates actual user experiences across real devices, real network conditions, and real browser states

Website speed testing is simultaneously one of the most measured and most misunderstood aspects of web performance. The gap between "my Lighthouse score is 95" and "my users are complaining the site is slow" is real, common, and explained by a specific set of factors that lab-based tools are structurally unable to capture.

The five performance metrics that matter for page experience

Google's page experience signals centre on Core Web Vitals, which have evolved since their introduction:

LCP (Largest Contentful Paint): time from navigation start until the largest visible content element (image, video poster, or text block) is rendered. Good: under 2.5 seconds. Poor: over 4 seconds. The most commonly discussed Core Web Vital.

INP (Interaction to Next Paint): replaces FID (First Input Delay) as of March 2024. Measures the full latency of the worst interaction in a page visit — from user input (click, tap, keystroke) to the next frame being painted with a visual response. Good: under 200ms. Poor: over 500ms. More comprehensive than FID, which only measured the first interaction.

CLS (Cumulative Layout Shift): measures unexpected visual shifts — content jumping as ads, images, or embeds load without reserved space. Good: under 0.1. Poor: over 0.25.

FCP (First Contentful Paint): first render of any DOM element. Less important as a direct ranking factor but useful for diagnosing where in the load sequence problems occur.

TTFB (Time to First Byte): time from navigation start to first byte of the server response. Primarily a server performance metric — high TTFB points to server-side problems (slow database queries, insufficient server resources, lack of caching) rather than client-side rendering issues.

Why Lighthouse and field data diverge

Lighthouse (Google's open-source tool, embedded in Chrome DevTools and PageSpeed Insights) simulates loading a page under defined conditions:

• Throttled network: typically simulates a "slow 4G" connection (10.4 Mbps download, 4.3 Mbps upload, 20ms base RTT) — regardless of your actual connection
• CPU throttling: multiplies CPU execution time by a factor (4× for mobile simulation) — regardless of your actual device
• Clean browser state: no extensions, no cached resources, no existing service workers, no cookies
• Single run average: typically averaged across 3-5 runs

CrUX (Chrome User Experience Report): collects real performance data from Chrome users who have opted in to usage statistics. Reports the 75th percentile (p75) of actual user experiences over the previous 28 days.

What real users have that Lighthouse doesn't:

Extension overhead: ad blockers, password managers, and productivity extensions run JavaScript that increases CPU load and memory consumption. Extensions regularly add 200-500ms to INP on complex pages.

Variable network conditions: mobile users on congested networks, rural users on 3G, users connecting from far geographic locations — all worse than Lighthouse's standardised throttling.

Real device performance variance: the CPU throttling multiplier attempts to simulate a mid-range Android phone, but actual device performance varies enormously. A 2019 budget Android phone may be 8-10× slower than a 2024 flagship — Lighthouse uses a single multiplier regardless.

Background tab loading: real users multitask. A page loading in a background tab competes for CPU with other active tabs.

The JavaScript execution bottleneck and INP

INP is now the Core Web Vital most frequently failed by complex web applications — particularly those built with React, Angular, Vue, or other SPA frameworks that perform significant JavaScript work in response to user interactions.

The INP failure pattern:

1. User clicks a button
2. JavaScript event handler fires
3. Handler triggers multiple state updates, API calls, and re-renders
4. All of this runs on the main thread — blocking the browser from painting
5. The user sees no visual response until the main thread is free
6. If this takes >200ms (good threshold) or >500ms (poor threshold), INP is poor

Why this is invisible in Lighthouse: Lighthouse measures interactions during the performance trace, but not the long-tail worst interactions that real users encounter on complex pages with many concurrent tasks.

The fixes:

• Code splitting: load JavaScript only when needed, reducing initial bundle size and main thread competition
• Scheduler API / scheduler.yield(): deliberately yield the main thread during long tasks, allowing the browser to paint between work chunks
• Web Workers: offload non-UI computation to background threads that don't block painting
• React 18 concurrent features / startTransition: mark state updates as non-urgent, allowing React to defer their rendering to avoid blocking urgent user interactions

CDN impact on TTFB and LCP across geographies

Content Delivery Networks dramatically affect TTFB for geographically distributed users — and TTFB is the starting point for every other metric:

Without CDN: all users fetch HTML from a single origin server. A user in Sydney accessing a server in London has a base TCP round-trip of approximately 270ms before any content can begin loading — contributing significantly to TTFB.

With CDN edge caching: the HTML is served from a CDN PoP near the user. Sydney users might fetch from a Sydney or Singapore PoP, reducing base TTFB to 15-30ms.

CDN's effect on Lighthouse scores: Lighthouse typically runs from Google's infrastructure (US-based). A UK-hosted site with no CDN may score well in Lighthouse (short round trip to UK from US is acceptable) but score poorly for Australian users in field data (Sydney to UK is slow).

The geographic score divergence: checking PageSpeed Insights field data vs Lighthouse lab data for sites without global CDN coverage often shows good lab scores (Lighthouse is run from a nearby location) but poor field data (international users on the 75th percentile distribution are far from the origin).

Image optimisation: the most common LCP problem

LCP failures are most commonly caused by the largest visible content element being an unoptimised image:

Common LCP image problems:

• No WebP/AVIF format: JPEG images that could be 40-70% smaller with modern formats
• No loading="lazy" vs loading="eager" distinction: lazy loading the LCP image means it starts downloading later, increasing LCP
• No explicit dimensions: images without width/height attributes cause layout shifts (CLS) as they load and also delay LCP because the browser can't allocate space without dimensions
• No fetchpriority="high": browsers don't know which image is most important without explicit hints; marking the LCP candidate with fetchpriority="high" starts downloading it sooner
• Image served from non-CDN origin: the LCP image's download time is directly affected by TTFB plus transfer time

The fetchpriority hint (supported in Chrome and Safari as of 2023): <img src="hero.webp" fetchpriority="high" loading="eager"> on the hero/banner image that is the likely LCP candidate can reduce LCP by 200-500ms on many pages.

How to use the Website Speed Test on sadiqbd.com

1. For establishing a baseline: test the same URL multiple times (5+ tests) and note the range — performance varies between runs; a single test result may not be representative
2. For geographic comparison: test from multiple locations if available — comparing your score from a US vantage point against a location closer to your actual user base reveals CDN gaps
3. For before/after validation: test before and after implementing a performance change (image format conversion, adding lazy loading, enabling server caching) to quantify the actual impact — critical for prioritising further optimisation work

Frequently Asked Questions

If Google uses CrUX field data for ranking signals, does my Lighthouse score directly affect rankings? No — Lighthouse lab scores are not used as ranking signals. Google's page experience ranking signals use CrUX field data (real user measurements) for the Core Web Vitals assessment. A page with a Lighthouse score of 95 but poor CrUX data (because real users on slow devices have poor INP) will be assessed by the CrUX data, not the Lighthouse score. PageSpeed Insights shows both lab data (Lighthouse) and field data (CrUX) when CrUX data is available for a URL — the field data section is what matters for Search ranking purposes. For pages without sufficient CrUX data (low traffic pages), Google falls back to the origin-level field data (aggregating all pages from the same domain).

Is the Website Speed Test free? Yes — completely free, no sign-up required.

Try the Website Speed Test free at sadiqbd.com — measure your site's loading performance and Core Web Vitals instantly.