time to first byte

Imagine timing a restaurant from the moment you finish ordering to the moment the very first dish reaches your table — not the whole meal, just how long until something starts arriving. Time to first byte (TTFB) is that measurement for the web: the time from when a client sends a request to when the first byte of the server's response arrives back. It captures the wait before anything useful starts coming, before the rest of the page or file even begins to download.

TTFB is the sum of several smaller delays stacked back to back. First the request travels to the server and the response's first byte travels back — at least one round-trip time (RTT), set largely by distance and the speed of light. On a fresh connection there is also setup: a DNS lookup, the TCP three-way handshake, and, for HTTPS, the TLS handshake, each adding round trips. Then the server needs time to actually produce the response — query a database, render a page — which is its processing delay. Add them up and you get TTFB; only after it does the browser begin receiving the body, leading eventually to full page load time, the moment the page is completely ready.

Why it matters: TTFB is a key diagnostic because it separates server-and-network responsiveness from download speed. A high TTFB points at distance, connection setup, or a slow backend — not at how big the file is. This is exactly where caching, CDNs, and connection reuse pay off: a CDN edge near the user cuts the RTT portion, a cache hit removes the backend processing, and a reused (persistent) connection skips the handshake round trips. The honest caveat: TTFB is just one signal. A fast first byte does not guarantee a fast page — a large body, many additional resources, or heavy client-side rendering can still make the full page slow long after the first byte arrives.