Static Signal
Signal vs Noise Web Performance Web Architecture

Your Lighthouse Score Is a Lie

Static Signal
A shattered speedometer pinned at 100, surrounded by floating performance metric icons on a dark purple background

You run Lighthouse. You get 100. You ship it.

Six weeks later, a client calls. Their site “feels slow.” You pull it up on your MacBook Pro, on fiber, with nothing else running. It snaps. You shrug and send them a screenshot of the score.

That screenshot is worthless. Here’s why.

Lighthouse Is a Lab Test, Not a Field Test

Lighthouse runs in a controlled simulation. It throttles your CPU and network, renders the page in a headless Chromium instance, and scores you against a set of weighted metrics. The inputs are synthetic. The conditions are predictable. The result is a number between 0 and 100 that tells you how fast your site could be — not how fast it is.

Google actually draws this distinction explicitly. They call it the difference between lab data and field data. Lighthouse is lab. Chrome User Experience Report (CrUX) is field. The two numbers are often wildly different, and field data is the one that matters to actual humans.

A 100 in Lighthouse means your site performed well under ideal synthetic conditions. It says nothing about:

  • Real users on Android mid-range devices
  • People in rural areas on 4G with variable signal
  • Your site under load with real CDN behavior
  • Third-party scripts that load after the audited render path
  • The cumulative jank from your marketing team’s tag manager setup

The Throttling Problem

Lighthouse’s simulated throttling is a rough approximation. When Lighthouse “throttles” your connection to simulate a mid-tier mobile experience, it’s not actually sending packets through a degraded network. It’s applying a multiplier to your local machine’s timings.

Your MacBook connected to gigabit fiber, after applying the multiplier, is still faster than a real Moto G4 on a congested LTE tower. The simulation smooths out the variance that real networks introduce — packet loss, retransmits, jitter, DNS resolution time under load. All of that gets averaged away.

This is why your Lighthouse score runs in the 90s and your real user monitoring shows a median Largest Contentful Paint of 4.2 seconds in India.

If you want to actually test on mobile, test on a real mid-range Android device. Buy a $150 phone, put it on your desk, and use it for every performance check. What you see there is what your users see. A browser devtools emulation is not the same thing.

Third-Party Scripts: The Score Laundering Operation

Here’s the most common way to get a perfect Lighthouse score on a site that is objectively slow in the real world: load all your third-party scripts after the audit window closes.

Lighthouse evaluates what happens during the initial page load and render. If your Google Tag Manager, Intercom widget, HubSpot tracking, A/B testing framework, and cookie consent banner all load asynchronously — tagged with defer or async, or lazy-initialized after user interaction — Lighthouse doesn’t penalize you for them. They don’t show up in your blocking time. Your score is pristine.

But your users experience all of it. Those scripts execute on their device. They consume CPU cycles during what should be the idle-after-load period. They trigger layout reflows. They fire network requests. Total Blocking Time in Lighthouse: 0ms. Total Blocking Time in the real world: several hundred milliseconds of frozen UI on a low-end device.

This isn’t a hypothetical. It’s how most marketing-heavy sites operate. They score well on Lighthouse because the audit methodology has a gap, and a generation of “performance optimization” work has been aimed squarely at closing Lighthouse’s gaps rather than improving the actual user experience.

The Metrics That Actually Predict User Perception

Lighthouse scores you on a composite of six metrics, each weighted differently. The weights have changed multiple times over the years. A site that scored 95 last year might score 80 today without a single line of code changing, purely because Google rebalanced the weights.

That’s not a performance change. That’s a scoring change. Don’t confuse the two.

The metrics worth actually caring about — the ones with direct ties to how users perceive your site — are the Core Web Vitals:

Largest Contentful Paint (LCP) measures how long until the largest visible element loads. This is the one users consciously notice. If your hero image or above-the-fold headline takes 4 seconds to appear, users feel it even if they can’t name it. Target: under 2.5 seconds.

Interaction to Next Paint (INP) replaced First Input Delay in 2024 and measures responsiveness across the full lifetime of the page — not just the first interaction. If clicking a button takes 500ms to visually respond because your JS thread is busy, INP catches it. FID didn’t. Target: under 200ms.

Cumulative Layout Shift (CLS) measures visual stability. When content jumps around as the page loads — because images don’t have dimensions, or a cookie banner pushes everything down — users lose their place. It’s disorienting and it erodes trust. Target: under 0.1.

These three metrics have field data you can actually measure. They’re in your Google Search Console. They’re tracked in CrUX. They’re what Google uses as ranking signals. Lighthouse’s composite score is not a ranking signal. LCP, INP, and CLS are.

What the Score Optimizes For

When you optimize for a Lighthouse score, you optimize for a specific kind of audit pass. You learn the rules of the game and you play them. That’s not inherently dishonest, but it’s worth being clear about what you’re actually doing.

Lighthouse rewards:

  • Render-blocking resource elimination. Move scripts to the bottom, add defer, get the points.
  • Image formatting. Convert to WebP, specify dimensions, pass the audit.
  • Cache headers. Add long-lived cache policies, score the points — even if your CDN is misconfigured and users are bypassing the cache entirely.
  • Unused JavaScript. Code-split your bundle and the warning goes away — even if you’ve just moved the cost to subsequent navigations.

None of these things are bad. Most of them are genuinely good practices. But they’re all auditable, which means they can all be gamed. Field performance is harder to game because it’s measured on real user devices in real conditions.

Getting Real Data

If Lighthouse is the test, here’s what actually measures performance:

Google Search Console — Core Web Vitals report. This is CrUX data for your actual site, segmented by mobile and desktop. It’s field data from real Chrome users. If you haven’t looked at this, look at it today. The numbers will probably be worse than your Lighthouse score.

Real User Monitoring (RUM). Tools like Vercel Speed Insights, Cloudflare Web Analytics, or open-source options like web-vitals.js collect performance metrics from every real page load and report back the distribution. You see the 75th percentile, not the synthetic median. The 75th percentile is what Google evaluates your Core Web Vitals against.

WebPageTest. This runs real browsers on real hardware, from real network locations, with real throttling. You can test from Mumbai on a real Android device over a real 3G connection. The results are often sobering. The waterfall charts are detailed enough to actually diagnose problems rather than just detect them.

Your own browser on a real mobile device. Disable caching, use the actual network, watch what happens. Not localhost. Not staging. The production URL, on the phone in your pocket, in the worst connectivity you can find.

The Audit Theater Problem

There’s a version of web performance work that exists purely to produce a passing grade. You’ve seen the deliverables: a PDF report, a before/after screenshot of Lighthouse scores, a line item in the proposal that says “performance optimization.”

The work is real. The score improvement is real. Whether users actually experience the site as faster is a separate question that often goes unasked.

This isn’t unique to performance. It’s the broader problem of optimizing for the metric rather than what the metric is supposed to represent. Lighthouse was designed to approximate real user experience. Over time, it has become a target in its own right — something to be achieved and reported, rather than a proxy for something deeper.

The agencies that understand this distinction are the ones worth working with. They’ll show you CrUX data. They’ll show you RUM percentiles. They’ll talk about LCP in terms of what image or element is triggering it and why, not in terms of what score improvement to expect.

Fixing the Right Things

If you’re doing serious performance work, here’s where the actual leverage is:

LCP almost always comes down to one of three things: the hero image loading too late, the server responding too slowly, or render-blocking resources delaying paint. Check which element is your LCP in a real-world trace and work backwards from there. The fix is usually either preloading the LCP image, improving server response time, or eliminating a render-blocking stylesheet.

<!-- Preload your LCP image — this one change often moves LCP by 0.5–1s -->
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high" />

INP problems are almost always caused by long tasks on the main thread. Break up your JavaScript into smaller chunks. Use scheduler.yield() or setTimeout(0) to yield back to the browser between expensive operations. Defer non-critical initialization until after first interaction. Profile with the Performance tab in DevTools — the flame chart will show you exactly where the main thread is blocked.

CLS is almost always fixable with explicit dimensions. Every image needs a width and height attribute. Every font needs a font-display strategy. If you’re using dynamic content above the fold, reserve space for it with min-height before it loads. These are mechanical fixes with predictable payoffs.

Server response time (TTFB) is the multiplier on everything else. A slow origin invalidates every other optimization downstream. If your Time to First Byte is over 600ms, your LCP target is basically unreachable regardless of what you do with JavaScript. Use a CDN, cache aggressively, and if you’re on a shared host that’s genuinely slow, that’s the bottleneck to fix first.

Use Lighthouse for What It’s Good At

Lighthouse is a useful development tool. It catches low-hanging fruit. It gives you a checklist of things to verify before you ship. It’s fast, it’s built into Chrome, and its recommendations are generally sound.

Use it the way you’d use a linter. It tells you about structural problems. It points out things you forgot to do. A score of 40 is a signal that something is genuinely broken. Fixing the issues it flags is usually worthwhile.

But a score of 100 is not a performance guarantee. It’s a passing grade on an exam that was designed for a specific kind of student in a specific kind of environment.

The real exam is what happens when someone in a city with spotty coverage opens your site on a two-year-old phone while waiting for a bus. Lighthouse was not in the room when that happened. CrUX was.

Check your Core Web Vitals in Search Console. Set up RUM on your production site. The numbers will tell you a different story than the score, and it’s the story that matters.