TTFB (time to first byte)

TTFB is the time from starting a request until the first byte of the response arrives. It bundles everything that happens before any content can render: DNS resolution, TCP and TLS handshakes, the request's travel time, the server's thinking time, and the first byte's trip back. That makes it the single best indicator of whether a response came from a nearby cache or from a distant, busy origin.

What's inside the number

1. DNS lookup — resolving the hostname (often cached, sometimes not).
2. TCP + TLS handshake — one to two round trips to wherever the connection terminates. With a CDN that's a nearby PoP; without one, your origin.
3. Server processing — for a cache hit, a memory/disk lookup (milliseconds); for a miss, the full origin render: application code, database, templates.
4. First byte back — one more one-way trip.

Note that tools measure slightly differently: browser metrics (CrUX, Lighthouse) count from navigation start including redirects; synthetic tools often report post-connection time. Compare like with like.

What's a good TTFB?

Google's Core Web Vitals guidance treats under 800 ms as good and over 1,800 ms as poor — but a cached edge response typically lands under 100 ms. The gap between those two numbers is almost always cache state and distance: an edge hit skips the origin entirely, while a miss pays the origin round trip plus render time. That's why the same URL can show a 50 ms TTFB in Frankfurt and 900 ms in Sydney — each PoP caches independently.

Measure it properly

A single measurement from your desk samples one location with a possibly warm cache. The global TTFB test measures from 8 locations at once, and the website speed test shows first vs. repeat visit per location — the delta between them is your caching win. For the deep dive into diagnosing and fixing slow TTFB, see our TTFB guide; for keeping edge caches warm so visitors never pay the miss penalty, that's cache warming.