What Is Time to First Byte (TTFB)?

How Time to First Byte Works

When a browser navigates to a URL, a series of steps happens before a single byte of HTML comes back. The browser may follow one or more redirects, resolve the domain name through DNS, open a TCP connection, negotiate TLS for HTTPS, and only then send the actual request. The server receives that request, runs whatever code it needs — routing, database queries, template rendering — and finally begins streaming the response. TTFB is the clock that runs across that entire sequence, stopping the instant the first byte arrives.

Because it spans so many phases, TTFB is best read as a waterfall rather than a single figure. Google’s documentation breaks it into redirect time, service worker startup (if one is registered), DNS lookup, connection and TLS negotiation, and the request phase up to the first response byte. Each phase is a candidate for optimization, and the largest one is where your effort pays off. A page with fast server code but a two-hop redirect can still post a poor TTFB purely from the redirect overhead.

TTFB matters for search because it sits underneath the metrics Google actually scores. First Contentful Paint and Largest Contentful Paint — the latter a Core Web Vital — cannot begin until markup starts arriving. As web.dev puts it, TTFB “precedes every other meaningful loading performance metric.” It is especially critical for client-rendered single-page apps, where the browser needs the initial response in hand before it can even start building the page.

The Phases of TTFB

TTFB is the sum of these sequential segments, in order:

• Redirect time — every hop from one URL to another before the final response, including HTTP-to-HTTPS and www normalization.
• Service worker startup — time to boot a registered service worker, if the site uses one.
• DNS lookup — resolving the hostname to an IP address.
• Connection and TLS negotiation — opening the TCP connection and completing the HTTPS handshake.
• Request-to-first-byte — the server receiving the request, processing it, and sending the first byte back.

Only the last segment is your application’s raw compute time. The rest is network and protocol overhead, which is why a CDN and clean redirects often move TTFB more than backend tuning does.

Example of Time to First Byte

The concrete numbers come straight from Google’s own thresholds. web.dev defines a good TTFB as 0.8 seconds or less and a poor TTFB as greater than 1.8 seconds, with the range between them marked “needs improvement.” Critically, these are not measured on a single lucky load: the guidance specifies the 75th percentile of page loads, segmented across mobile and desktop, so three out of four real visits must land inside the threshold before a site is judged fast.

The reason Google anchors on 0.8 seconds is spelled out in the same documentation: it is a rough budget that leaves enough headroom for the rest of the loading sequence to finish inside the “good” range for First Contentful Paint. In other words, the number is derived from what has to happen after the first byte, not chosen arbitrarily. If TTFB alone eats 1.5 seconds, there is simply no way for FCP or LCP to reach a good score, because those metrics are stacked on top of it.

That framing is the whole practical lesson. TTFB is a ceiling, not a vanity stat. You can inline critical CSS, defer scripts, and compress images perfectly, and the page will still feel sluggish if the server takes 1.8 seconds to answer. This is why performance audits start at the first byte and work outward: fix the floor, then optimize what sits on it.

Frequently Asked Questions

The Bottom Line

TTFB is the stopwatch reading at the moment your server first speaks. Everything a visitor sees is queued behind it, so a page that takes two seconds to return its first byte can never feel fast no matter how lean the rest of the build is. Treat it as the floor under every other speed metric, and diagnose it phase by phase rather than as a single number.