Domains, CDN & Web Delivery

Time to First Byte

Definition

TTFB is a sum of several distinct stages, and knowing which one dominates is the whole point of measuring it. The clock starts at navigation and covers any redirect, the DNS lookup, the TCP handshake, the TLS handshake, sending the request, the server thinking about it, and the response travelling back. Google's guidance treats 800 ms as the boundary for good and 1.8 seconds as poor, measured at the 75th percentile of real visits. A static file served from a nearby edge node usually lands between 50 and 200 ms; an application server building a page from a database on another continent can easily pass a second. In a browser's network panel it appears as the Waiting or TTFB row, and in code it is responseStart minus startTime on the navigation timing entry.

Why It Matters

Nothing else on the page can start until the first byte lands, so TTFB is a floor under every other timing you care about. If it takes 900 ms, then Largest Contentful Paint cannot be better than 900 ms no matter how small the hero image is — you have spent more than a third of the 2.5 second target before a single tag has been parsed. It is also the number most often ruined by something unrelated to the page itself: one careless redirect from http to https, then from the apex to www, can add two full round trips before the real request even begins. Fixing TTFB is usually cheap, because the causes are structural rather than a matter of shaving kilobytes.

How It Works

Break the number apart before touching anything. A slow DNS stage points at a low-value nameserver or a cold cache; a slow connect stage points at distance, which is what an edge network exists to remove; a slow wait stage points at the server or origin. For static content the fix is usually caching: a response served from a CDN edge that already holds the file skips the origin entirely, which is why cache hit ratio and TTFB move together. Keep redirect chains to at most one hop, since each one repeats the whole sequence. On the origin side, sending headers early — and letting the server flush the start of the HTML before the page is fully assembled — moves the first byte forward even when total work is unchanged.

Real-World Example

A consultant hosts a 240 KB proposal page on 99helpers at northgate-proposal.99helpers.site. From London the first byte arrives in about 70 ms, since the file sits on an edge node a few milliseconds away and nothing has to be generated. The same page on the consultant's old shared server, rendered per request in another country, returned its first byte after roughly 950 ms — more than 13 times longer, for identical bytes.

Common Mistakes

  • Treating TTFB as the page speed score — a fast first byte followed by three render-blocking scripts is still a slow page
  • Measuring from a fast office connection near the server, which hides the distance every real visitor pays for
  • Leaving a redirect chain in place, where each extra hop adds a full DNS, TCP and TLS sequence before the real response starts
  • Blaming the server when the delay is in DNS resolution, which the waterfall shows as a separate stage

Related Terms

Put a file online in seconds

Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.

Host a file free →