The PageSpeed score is the 0–100 headline number in PageSpeed Insights and the Lighthouse Performance category. It is not one measurement. It is a weighted average of five lab metrics, each scored on a curve against a reference set of real sites, then combined.
How the weighting works
Lighthouse 10 and 11 weight the five metrics like this:
| Metric | Weight |
|---|---|
| TBT (Total Blocking Time) | 30% |
| LCP (Largest Contentful Paint) | 25% |
| CLS (Cumulative Layout Shift) | 25% |
| FCP (First Contentful Paint) | 10% |
| SI (Speed Index) | 10% |
Because TBT, LCP and CLS make up 80% of the score, that is where almost all the movement is.
The colour bands
The Good / Needs-work / Poor bands sit in the summary panel and map to the familiar green, orange and red badge. The curve behind them is deliberately steep at the top: moving 90 → 100 can take as much work as 40 → 70, because the last points require near-perfect metrics.
Being a blend makes it noisier than its parts
A composite of five metrics inherits the instability of the least stable one, and that is TBT, which depends on how busy the CPU happened to be. We have measured a sixteen-point spread across six consecutive runs of the same URL while the underlying Speed Index barely moved.
That was one URL. Across 443 mobile measurements of pages as their owners serve them, the rounds inside a single measurement disagreed by 9 points at the median, and 18% of them put two rounds in different colour bands (the measurement).
The practical rules that follow are unglamorous. Take the median of at least three runs, and check that the repeats actually ran rather than being served from a cache (how to). When the score and the metric disagree about whether something improved, believe the metric. And treat any reported gain narrower than the observed run-to-run spread as no gain at all, which is why some of the audits in our own base are marked “needs a re-measure” rather than given a number.
What a headroom figure looks like when it is real
The counterpart to a noisy score is a gain large enough to survive the noise. On nine WordPress sites run by the performance industry itself, the median mobile score moved from 51 to 69 with no plugin added or removed, entirely from reordering the critical path. One site went from 51 to 97. Those are medians of three runs each, on sites checked first for the redirect leak that would have made the comparison meaningless.
What drags the number down
- A slow LCP, from a late hero image or a render-blocking
<head>, costs a quarter of the score on its own. - High TBT from blocking JavaScript. Heavy third-party and un-deferred scripts tie up the main thread, and TBT is the heaviest metric at 30%.
- Poor CLS. Unsized images and content injected after load shift the layout and cost another quarter.
- The throttled mid-tier mobile simulation, which scores the same page far harsher than your laptop does.
Lab result, not verdict
The PageSpeed score is a lab result: one simulated load on a throttled device. It is not your Core Web Vitals assessment, which comes from real users. A page can score 95 in the lab and still fail CWV in the field, or the reverse. Treat the score as a diagnostic you can act on, and the field data as the verdict.
Which metrics we attack first
WebSpeed targets the heavy-weight metrics first: cutting TBT by deferring scripts, pulling LCP in with preload and critical-CSS inlining, and killing CLS with real aspect-ratios. That is why proxied pages typically move up a whole colour band.