Why Your PageSpeed Score Isn't Telling the Whole Story

The dev was proud: "100/100 on PageSpeed, both mobile and desktop." Two weeks later, the same site showed up failing Core Web Vitals in Search Console — LCP "poor" for 31% of URLs. It wasn't a bug. The 100/100 was accurate. And the site was still slow for real users.

That's the paradox nobody explains properly: you can score a perfect 100 on PageSpeed and still have a site that frustrates users and loses ranking ground.

What the PageSpeed score actually measures

The 0–100 number PageSpeed Insights displays is not a direct speed measurement. It's a weighted average of lab metrics, calculated by Lighthouse running under simulated conditions on Google's servers.

In 2026, the approximate weights are:

Two critical points here.

First: TBT is not a Core Web Vital. It's a lab proxy for INP — it measures main thread blocking time during page load. The correlation is real but imperfect. A site can have very low TBT in the lab and terrible INP in the field if the heavy work happens in post-load interactions, not during boot.

Second: CLS has a 25% weight, but its impact on the score is non-linear. A CLS of 0.05 (good) scores well. A CLS of 0.12 — only 0.02 above the threshold — can tank the score significantly. This creates incentives to optimize what moves the number, not necessarily what most affects users.

Why 100/100 doesn't mean a fast site

Lighthouse runs under specific conditions: emulated Moto G Power, simulated slow 4G via software throttling (10 Mbps down, 40 ms RTT). That's one condition. Your audience is another.

If your users are on budget Android phones with patchy 3G in rural areas, they have worse hardware and connectivity than Lighthouse's benchmark. If your audience is mostly desktop users on fiber abroad, Lighthouse is being more pessimistic than reality. In both cases, the lab score and real experience diverge.

The high-score + bad-experience scenario typically shows up when:

1. The site loads fast, but gets slow after mount

SPAs are the champions here. Lighthouse measures the initial load. If the page mounts in 1.2s but spends the next 3 seconds fetching data and populating components, Lighthouse gives a good score. The user sees a spinner. CrUX will catch this in INP, but the lab score won't.

2. Software throttling underestimates bad mobile networks

Lighthouse simulates 4G by delaying packets via software, which doesn't capture the effects of jitter and packet loss on real mobile networks. WebPageTest with hardware throttling (or testing on a physical device with a proxy) consistently shows worse metrics for the same nominal connection. You pass in Lighthouse, fail in reality.

3. The LCP element changes between desktop and mobile

You optimized the desktop hero with fetchpriority="high" and preload. On mobile, the layout is different — the "largest element" is a text block in the middle of the page with no preload. Desktop score: 94. Mobile score: 61. And CrUX segments by device type too.

4. Third-party resources load after the measurement window

Lighthouse has a limited measurement window. Third-party scripts (chat widgets, tracking pixels, A/B test scripts) that load 4–6 seconds after DOMContentLoaded don't affect the lab score. But they block the main thread when they arrive, increasing INP at exactly the moments users are trying to interact. Field data catches this. Lab data doesn't.

The number that affects rankings is not the score

This point deserves to be explicit: Google does not use the 0–100 score as a ranking factor. What affects rankings are Core Web Vitals measured in the field, via CrUX.

The assessment is binary per metric: pass or fail. The 2026 thresholds:

• LCP ≤ 2.5s (field, p75) — pass
• INP ≤ 200ms (field, p75) — pass
• CLS ≤ 0.1 (field, p75) — pass

If 75% of your real users have LCP below 2.5s, you pass. If Lighthouse simulates 1.8s but real users at the p75 have 3.1s, you fail — regardless of the score.

As of June 2026, 55.9% of origins tracked by CrUX pass all three Core Web Vitals simultaneously. Nearly half of sites on the web still fail at least one metric, despite many having apparently acceptable lab scores.

Optimizations that only improve the number

There's a class of optimizations that raise the score without improving the real experience. Recognizing them avoids wasted effort.

Removing resources Lighthouse flags but that don't affect real users

Lighthouse penalizes unused JavaScript. Aggressive automated tree-shaking can remove interaction code that's only activated by events — code that looks "unused" during initial load but is critical for INP. Score goes up, interactions break.

Optimizing only the tested page

PageSpeed evaluates one URL at a time. Some teams optimize the homepage to 95+ and ignore product pages — which have more traffic, more conversion impact, and are sitting at 55. CrUX will catch those product URLs in Search Console.

Minifying everything that doesn't need minification

Minification has rapidly diminishing returns. If HTML is already gzipped at the CDN, saving 2KB on an 8KB file won't move the needle on LCP. But it will take engineering hours that could go toward investigating why CrUX shows poor LCP on mobile.

Replacing web fonts with system fonts just to kill the audit

Lighthouse penalizes fonts that cause FOUT. Switching Inter to -apple-system, Segoe UI, sans-serif removes the warning and boosts the score — but also removes visual consistency across platforms. That's a product decision, not a performance optimization. Don't let a lab audit make that call for you.

How to read PageSpeed Insights without being misled

PSI has two distinct blocks and most people only look at the score:

┌─────────────────────────────────┐
│  FIELD DATA (CrUX)              │  ← this affects rankings
│  LCP: 2.1s ✓  INP: 180ms ✓     │
│  CLS: 0.08 ✓                    │
├─────────────────────────────────┤
│  Performance: 87               │  ← lab score
│  (Lighthouse Diagnostics)       │  ← doesn't affect rankings
└─────────────────────────────────┘

Practical rule: read top to bottom, not bottom to top. The field data block is at the top for a reason — it's the most important. The score is at the bottom because it's secondary.

If the field block shows all three metrics in green, you've passed on what matters to Google. The lab score is still useful for diagnosing regressions and finding problems, but it's not the finish line.

If the field block is absent ("No field data available"), your site has insufficient traffic in CrUX. In that case, use lab data as a proxy, instrument the web-vitals library to collect your own field data, and accept that Core Web Vitals may not be an active ranking factor yet.

When a high score is a warning sign

There's a specific situation where a very high score should raise suspicion: when it was achieved recently after a prolonged period of low scores, without obvious code changes.

What sometimes happens is the site got smaller — in functionality. Third-party scripts were removed without checking impact. Interaction components were simplified. Fonts were swapped. The score went up because the product shrank, not because it got more efficient.

The lab score doesn't measure delivered value. It measures technical load characteristics under simulated conditions. A site that does fewer things will always score better than an equivalent site that does more. Sometimes that's great (removing unnecessary bloat). Sometimes it's dangerous (removing functionality that has value).

To understand what Search Console is showing in terms of real field data — broken down by device type and URL — the post how to actually measure your site's speed covers the full workflow, including how to interpret CrUX data per specific URL.

Frequently asked questions

Why does my score change between two consecutive runs?

Lab data has natural variance. Lighthouse runs on Google's shared servers — CPU state, timing of third-party requests, CDN cache hits and misses can all vary between runs. A difference of ±5–8 points is normal and expected. What matters is the trend across multiple runs, not a single reading. To reduce noise, run three times and use the median.

Does a high PageSpeed score guarantee better Google rankings?

Not directly. The lab score is not used as a ranking factor. What Google evaluates are field Core Web Vitals (CrUX), measured at the 75th percentile of real users. It's possible to have a 95 lab score and fail in the field — usually because real users are on worse devices or networks than Lighthouse's benchmark.

Is it worth chasing 100/100, or is it a waste of time?

It depends. If you're at 50/100 with poor INP and a 4-second LCP, improving to 85 will meaningfully improve real experience and SEO. If you're at 90/100 with all field metrics green, spending time to reach 100 is diminishing returns — the effort is probably better spent on content or functionality. The threshold that matters is field data being green, not the lab hitting 100.

How do I know if my real users are having a good experience?

Through Search Console (Core Web Vitals report), the "Field Data" block at the top of PageSpeed Insights, and the web-vitals library instrumented in your code. These three sources show what's actually happening with real users — not what the lab simulates.

The score is the thermometer, not the fever

A PageSpeed score is useful as a diagnostic thermometer — it indicates something might be wrong and where to investigate. But it's not the fever itself. The fever is high LCP for real users, slow INP in critical interactions, CLS breaking the layout mid-scroll.

Optimizing for the number instead of the experience is like taking fever reducers to look healthy on the measurement. The thermometer drops, the infection continues.

For generating and testing site meta tags while working on performance — og:image, description, title — I use the Meta Tag Generator to check the preview before deploying, without needing a full deploy to see how it'll appear on Google and social media.