This page is about one tool’s data: the Page Speed & Size Test. For how these scores sit alongside the other measures, the distributions in full and the methodology, see SEO Score Benchmarks.
Which speed check is missed, and how often
The tool takes a URL, fetches the page once from the server side and runs seven checks: time to first byte, total load, compression, caching headers, HTML weight, the number of render-blocking files and the number of images. The percentage below is the share of runs in which the check did not pass.
| Check | Did not pass | Weight |
|---|---|---|
| Reasonable image count | 34% | Partial |
| Browser caching headers | 27% | Partial |
| Limited render-blocking JS/CSS | 19% | Partial |
| Fast Time to First Byte | 13% | Hard fail |
| Compression enabled | 12% | Hard fail |
| Reasonable HTML weight | 5% | Partial |
| Quick total load | 1% | Partial |
The shape of the list says more than any single row in it. The top three items — image count, caching headers, render-blocking files — are scored as partial credit lost: none of them slows a page down alone, all of them do together. The two hard fails below them are not about the page at all, but about its server. The average scan passes 5.9 of the seven checks and leaves only 1.1 open items behind it — the cleanest check list in the dataset.
Why almost everyone scores high here
81% of scans score 80 or above, and the 75th percentile sits at 100 — a quarter of the sample is at or near a perfect score. 14 scans graded F against 432 at A+. The reason is what is being measured: the delivery layer. Compression is switched on by the host, caching headers are added by a CDN, response time is absorbed by a managed platform. The work a site owner used to do by hand now arrives by default, and the score reflects that.
Which is why reading a speed score as an achievement is a mistake. When a page scores 90 here, what you have learned is not that it is faster than its competitors — it is that it sits on a modern hosting stack. The separation is not in this measure but in the ones nobody gets by default: on E-E-A-T the median is 38/100. That distance is the single biggest finding in the whole dataset.
The category split says the same thing: Speed & Delivery was the lowest-scoring category in 60% of runs and Payload & Requests in 40%. The balance between them shows where the speed problem has moved: pages are losing points less for being too heavy than for not being handed over fast enough.
Both remaining hard fails are server-side
Two of the seven checks are scored as hard fails, and neither has anything to do with the content of the page. Time to first byte is over its threshold in 13% of runs; compression is not switched on at all in 12%. The second is the striking one, because enabling Gzip or Brotli typically cuts text transfer by 60–80% and is a single server setting — no content changes, no template changes, no page rewritten. Total load time, meanwhile, exceeds its limit in only 1% of runs.
The practical consequence is that raising a score on this measure is almost never work on the page. Switch on compression, set Cache-Control headers, cut the server response time. All three are done once, in an afternoon, for the entire site — the only item on the list that has to be fixed page by page is the image count at the top of it.
What this score does not measure
Reading these figures correctly means knowing where the measurement stops. The tool fetches the page once from the server side and measures the connection, the first byte, the size of the response and its headers. It does not open the page in a browser, does not execute JavaScript, cannot see layout shift (CLS) or interaction delay (INP), and does not look at real-user data. So scoring 90 here means the delivery layer is clean; it does not mean Core Web Vitals pass. A page shipping a heavy JavaScript bundle can come out of this test with a high score and still be slow on an actual phone.
Frequently asked questions
What is a good page speed score?
In this dataset the median is 90/100, so a typical page already scores high. 81% of scans reach 80 or above; the 25th percentile is 80 and the 10th is 71. The practical reading is that 80 on speed does not put you ahead, it only makes you ordinary. Separation starts at 100 and above — and getting there usually means fixing the server, not the page.
Is 90 here the same as 90 in PageSpeed Insights?
No, and the two should not be read side by side. This tool makes a single server-side request and measures the connection, the time to first byte, the size of the response and its headers. It does not run the page in a browser, execute JavaScript, or observe layout shift or interaction delay. PageSpeed Insights combines field data from real Chrome users with a full browser trial. A high score here means the delivery layer is clean; it does not mean Core Web Vitals pass.
Which speed check is missed most often?
Reasonable image count — it does not pass in 34% of runs. Browser caching headers follow at 27% and render-blocking JS/CSS at 19%. All three are scored as partial credit lost rather than hard fails, because none of them slows a page down on its own. They slow it down together.
Does time to first byte matter more than total load time?
In this sample the question answers itself: total load time exceeds the threshold in only 1% of runs, while time to first byte is over its limit in 13%. TTFB is scored as a hard fail because it delays everything after it — while the browser waits for the first byte it can download nothing, parse nothing and paint nothing. A slow first byte is not recoverable by optimizing what comes next.
The sample, the methodology, the anonymization and the CC BY 4.0 licence are all set out in the methodology section on the hub.