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.