A while back I got curious about a simple question: how fast are the websites everyone actually links to? Not the hand-picked case studies you see in conference talks — the real ones sitting at the top of the link graph. So I pulled roughly the 5,000 most-referenced domains on the web and measured how long each took to return the first byte of its homepage. 4,392 answered cleanly. Here's what came back.
The short version
The median site responded in 474ms. Not great, not terrible — the kind of number that looks fine on a slide and feels sluggish in a browser.
The problem is the tail. Past the median, things come apart fast:
| Percentile | Response time (TTFB) |
|---|---|
| 50th (median) | 474 ms |
| 75th | 898 ms |
| 90th | 1,570 ms |
| 95th | 2,108 ms |
Read that last line again. One in twenty of the web's most important sites takes over two seconds just to start responding — before a single byte of HTML has been parsed. And 21.5% cross the one-second mark. These aren't obscure blogs; they're the domains with the most inbound links on the internet.
The buckets
Grouping the whole sample says the same thing more bluntly:
- Under 200ms (genuinely fast): 22.7%
- 200–500ms (fine): 29.4%
- 500ms–1s (you'd notice): 26.4%
- Over 1s (slow): 21.5%
So a little under half is "fine or better," and a little over half sits somewhere between noticeable and painful. For a list that skews heavily toward big, well-funded, technically sophisticated organizations, that was worse than I expected going in.
A few names that stood out
Some big, reputable sites turned in genuinely rough numbers:
- douban.com — about 9.9 seconds
- eetimes.com — about 9.3 seconds
- openjdk.org — about 9.3 seconds
- itu.int — about 7.9 seconds
None of these are broken. They just take their time. Which is a decent reminder that brand size and server speed have almost nothing to do with each other.
Why the first byte is worth caring about
TTFB is the part of page load nobody sees and everybody pays for. It's your server thinking — database queries, template rendering, whatever the backend does before it hands anything to the browser. It sets the floor for everything after it: your Largest Contentful Paint can't be quick if the first byte shows up at the 1.5-second mark.
Google folds this into Core Web Vitals, so it isn't just a UX nicety — a slow first byte quietly drags on rankings. It's also usually the cheapest thing to fix relative to how much it moves: a cache layer, a CDN, or killing one slow query often does more than weeks of front-end tuning.
Two things we noticed along the way
Security is basically a solved problem at the top of the web. Not one site in the sample earned an F, because HTTPS is universal here. But the good end is rare — only 4.4% shipped the full set of security headers (a strict CSP, HSTS, the rest). Most do the bare minimum and stop.
Content, meanwhile, is quietly the weakest area across the board. Homepages tend to be thin, and structured social markup (Open Graph tags) is close to a coin flip — plenty of major sites still skip it.
How we did this
We took the top ~5,000 domains by referring subnets (the Majestic Million list), fetched each homepage server-side, and recorded time-to-first-byte alongside the on-page factors our analyzer already checks. 4,392 returned a clean HTML response; the rest timed out, blocked automated requests, or served something that wasn't a page. TTFB was measured from a single location, so any one number is a relative signal, not a lab reading — but the shape of the distribution across thousands of sites is the interesting part, and that holds up.
Curious where your own site lands? Run it through SEO Snapshot — it reports your response time against this benchmark, plus the on-page and security checks from the same pass.
FAQ
Q: What is a good TTFB (Time to First Byte)? Aim for under 800ms; under 200ms is genuinely fast. In our measurement of 4,392 top sites the median was 474ms, but the 75th-percentile site already sat at 898ms, so many well-known brands miss the mark.
Q: Does TTFB affect SEO and Core Web Vitals? Indirectly but meaningfully. A slow first byte delays every step that follows, pushing out Largest Contentful Paint (a Core Web Vitals metric Google uses for ranking) and eating into crawl budget. It is not a direct ranking factor on its own, but it caps how fast the rest of the page can possibly load.
Q: Why was one in five top sites slow in this study? The biggest, most controllable slice of TTFB is server processing. Sites without full-page caching, a CDN, or fast database queries spend that time on the backend before sending a single byte, which is why even high-traffic brands landed over one second.
Q: How do I reduce a high TTFB? Cache the response so the backend does little or no work, put a CDN in front to cut physical distance, speed up slow or N+1 database queries, and move render-on-request pages to static or edge rendering. These target the server-processing slice, where nearly all the wins are.