In web performance, what does Time to First Byte (TTFB) measure for a page navigation, which phases of the request are folded into that single number, and why does a high TTFB drag the paint metrics with it?

## What the metric actually is Time to First Byte is the interval between the browser beginning a navigation — the moment it commits to fetching a new document — and the arrival of the **first byte of that document's response**. It is not the first byte of any resource, and it is not the first pixel. It is one number describing the entire round trip for the HTML. TTFB is not one of the Core Web Vitals. It is a *supporting* or *diagnostic* metric: nobody ships a product because TTFB is green, but when LCP is bad, TTFB is the first place you look to decide whether the problem is even in the browser at all. ## Everything that hides inside the number A navigation's TTFB is a sum of phases that have nothing to do with each other: - **Redirects.** Each redirect is a complete request and response of its own, and its time is charged to TTFB. A chain like `http://example.com` → `https://example.com` → `https://www.example.com` → `https://www.example.com/en/` costs three extra round trips before the real document is even requested. - **Service worker startup.** If a service worker controls the navigation, the time to boot it and run its fetch handler counts. - **DNS lookup**, on a cold resolver cache. - **TCP connection** (or QUIC handshake) and **TLS negotiation**. On a new origin over a long distance these are multiple round trips before a single application byte moves. - **Request send + server think time.** The application's own work: routing, authentication, database queries, template rendering. - **The first byte travelling back** across the network. The practical consequence is that "TTFB is 1.4s" tells you almost nothing on its own. Two sites with identical TTFB can need completely opposite fixes — one is spending 1.2s in the database, the other is spending 1.2s on connection setup from another continent. ## Why it is a floor under everything else The HTML parser cannot start until bytes arrive. No stylesheet is discovered, no script is queued, no image URL is known. So First Contentful Paint, Largest Contentful Paint and every other load metric sit strictly *after* TTFB on the timeline. If you shave 400ms off TTFB and change nothing else, the paints typically move about 400ms earlier too — TTFB improvements propagate almost one-for-one, which is what makes them unusually high-leverage compared with micro-optimizing the front end. The converse is the more important interview point: if TTFB is 2.5s, no amount of image optimization, preloading or code splitting will produce a good LCP. The budget is already spent. ## Reading a bad TTFB The diagnosis is a decomposition, not a single answer: - **Connection phases dominate** → the user is far from the origin, or connections are not being reused. This is the case edge termination and connection reuse address, because the expensive handshake happens close to the user. - **Server phase dominates** → it is a backend problem: an uncached query, a slow upstream, a cold serverless instance. No front-end change will help. - **Time appears in discrete steps** → redirects. Count them and collapse them; canonical host and scheme should be one hop at most. - **First byte is fine but the page still feels slow** → the response is streaming slowly. TTFB only describes the *first* byte; a server that flushes a `<head>` immediately and then blocks for a second on data has an excellent TTFB and a poor experience. ## Where TTFB misleads Because TTFB is measured per navigation, several situations distort it. A back/forward-cache restore or a service-worker-served response can produce a near-zero TTFB that says nothing about how fast the site is for a first-time visitor. Client-side route changes in a single-page app are not navigations at all, so they contribute no TTFB — a slow SPA can post excellent TTFB numbers forever. And field TTFB is dominated by the *distribution* of your users' networks and locations, so a value that looks bad may be mostly last-mile latency you do not control. A useful mental model: TTFB is the cost of *getting permission to start*. It is the only metric on the page that is largely decided before the browser has drawn anything, and it is the only one a purely front-end change usually cannot fix. ## What actually moves it Serving the HTML from a cache close to the user, cutting redirect chains, reducing server work (query caching, avoiding cold starts), and streaming the response so the first byte is not held hostage to the slowest data fetch. Informational `103 Early Hints` responses are worth knowing about here as well — they let the browser start fetching critical subresources during the server's think time, which does not shorten the document's TTFB but stops that time from being pure waste.