TTFB explained: why some sites feel slow even on fast internet
You click a link. For two full seconds: nothing. White screen. Then, suddenly, the whole page appears at once. Your speed test says 500 Mbit/s, so what were those two seconds?
They were TTFB — Time To First Byte: the gap between asking for a page and receiving the very first byte of the answer. It's the silent part of every page load, it has almost nothing to do with your bandwidth, and it's the single best number for telling whether a website's own machinery is struggling. It's also the number our test measures from the server side.
Where the waiting happens
Before the first byte can arrive, four things happen in sequence:
| Step | What it is | Typical cost |
|---|---|---|
| DNS lookup | Translating the name into a server address | 5–120 ms (often cached: ~0) |
| Connection | Establishing the TCP connection | 1 round trip to the server |
| Encryption | The TLS (https) handshake | 1–2 more round trips |
| Server think time | The site assembling your page: database queries, code, caches | 5 ms – many seconds. The wildcard. |
Notice that the first three are priced in round trips — so physical distance sets the floor. A round trip to a server in your own country takes maybe 10–30 ms; to another continent, 100–200 ms. Three round trips to a server 150 ms away = 450 ms before the server has even begun thinking. That's why big sites pay for CDNs: shortening every round trip by serving you from a node nearby.
But the wildcard — the thing that turns a snappy site into a two-second white screen during an incident — is almost always server think time. Overloaded databases, exhausted caches, a bad deploy: they all show up as ballooning TTFB long before the site actually goes down.
What counts as slow
- Under 200 ms: good — the page starts arriving before you notice waiting.
- 200–500 ms: normal for dynamic sites without aggressive caching.
- ~800 ms: the level Google's Core Web Vitals guidance flags as poor.
- Over 1,500 ms: our threshold for calling a site slow — at this point the site's own infrastructure is nearly always the bottleneck, not the path to it.
Why your bandwidth can't help
Bandwidth is how wide the pipe is. TTFB is how long before anything enters the pipe. Once a struggling server finally starts answering, your gigabit line will happily gulp the page in a tenth of a second — but it waited the same two seconds a 50 Mbit/s line would have. Upgrading your plan to fix high TTFB is buying a wider pipe for a tap that's stuck.
This is exactly why one site can crawl while the rest of your internet flies: your connection is a shared factor across all sites, but every site brings its own TTFB. (The full symptom checklist is in internet or website?.)
Run the 10-second test →
One subtlety: high TTFB on *your* end
Two cases where TTFB looks bad but the site is innocent:
- Your latency is the floor. On satellite internet or a congested mobile network with 300+ ms round trips, every site's TTFB looks bad from where you sit — three round trips of 300 ms is nearly a second before think time. This is why measuring from a second location matters: our probe checks the site from a data-center connection, so if TTFB is fine from there and terrible from you, the verdict is you, not them.
- A VPN adds a detour. Routing through a VPN node in another country adds its distance to every round trip. Turn it off and re-test before blaming anyone.