Time to First Byte (TTFB) Explained

Time to First Byte (TTFB) measures how long a browser waits between sending a request and receiving the first byte of the response. It bundles together everything that happens before the server starts sending content back: DNS resolution, connection setup, TLS negotiation, server processing, and network transit — making it one of the earliest and most diagnostic signals in a page load, even though it isn’t one of the Core Web Vitals themselves.

What TTFB actually measures

TTFB is the sum of several distinct delays, which is exactly why it’s useful for diagnosis — a high TTFB always points somewhere specific once you break it down:

1. DNS lookup — resolving the domain to an IP address, unless cached.
2. Connection setup — the TCP handshake, plus the TLS handshake for HTTPS connections.
3. Request sent — the browser transmits the request.
4. Server processing — the backend does whatever work is needed to build a response: routing, database queries, template rendering, business logic.
5. Response begins — the first byte of the response arrives back at the browser.

A slow TTFB can come from any one of these. A cold DNS cache, a distant server with high round-trip latency, an unoptimized TLS configuration, or slow backend processing all show up as the same symptom — a delay before content starts arriving — but they call for completely different fixes.

Why it matters even though it’s not a Core Web Vital

Google’s Core Web Vitals — Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift — measure user-perceived outcomes, not the individual mechanics that produce them. TTFB isn’t one of them, but it’s a leading contributor to LCP in particular: nothing else on the page can render, hydrate, or paint until the first byte of HTML arrives, so a slow TTFB puts a floor under every downstream metric. Optimizing everything after the first byte — critical rendering path work, image compression, script loading order — can’t compensate for a server that takes seconds to start responding.

Common causes of a slow TTFB

Server-side processing. Complex database queries, unoptimized backend logic, or synchronous work on the request path all delay the moment the server has anything to send. This is often the biggest lever — a page rendered server-side with a slow database call will show a high TTFB no matter how fast the network is.

Distance to the server. Physical and network distance between the client and the origin server adds unavoidable round-trip time. This is the problem a CDN solves for static and cacheable content — serving from a point of presence near the user instead of a single distant origin.

No caching. A response generated fresh on every request pays the full server-processing cost every time. HTTP caching headers let a CDN or browser skip the round trip to origin entirely for content that hasn’t changed, which is often the single largest TTFB improvement available for content that doesn’t need to be regenerated per request.

Redirect chains. Every redirect the browser follows before reaching the final URL adds a full round trip before that request even begins, compounding directly into a higher effective TTFB for the page the user actually lands on.

Protocol overhead. The number of round trips needed just to establish a connection matters — this is one of the areas where HTTP/2 vs. HTTP/3 differ, since HTTP/3’s QUIC transport can establish a secure connection in fewer round trips than the TCP-plus-TLS handshake HTTP/2 requires, shaving real time off TTFB before a single application byte is exchanged.

Reducing TTFB

Serving from the edge is usually the highest-leverage fix for TTFB where it’s an option: platforms like Cloudflare Pages, which is how sites such as this one are deployed (see deploying Astro to Cloudflare Pages), serve cached and SSG content directly from points of presence near the user rather than a single origin, cutting network latency out of the equation for anything that doesn’t need to be generated per request. Edge computing pushes this further by running actual server logic near the user rather than only caching static output.

For content that must be dynamic, resource hints matter too: preconnect lets a browser complete DNS, TCP, and TLS setup for a critical origin before the request that needs it is even issued, overlapping connection setup with other page work instead of paying for it serially. And ensuring responses are compressed with something like Brotli or gzip doesn’t reduce TTFB itself — that’s measured to the first byte, before compression’s benefit on transfer size applies — but it’s frequently bundled into the same performance pass and pays off on the metrics that follow.

How to measure it

TTFB is reported directly in browser DevTools’ network panel as part of a request’s timing breakdown, and is exposed programmatically via the Navigation Timing API as responseStart relative to requestStart. Real-user monitoring tools capture it in the field, across the actual mix of networks and devices your users have — which matters, since lab measurements from a single location with a fast connection routinely understate what users on slower networks or farther from your servers actually experience.

The takeaway

TTFB is the delay before any content starts arriving at all, and because nothing else on the page can begin until that first byte lands, it puts a hard floor under every downstream performance metric, LCP especially. Slow TTFB almost always traces back to one of a few causes — distant servers, uncached dynamic responses, slow backend processing, or unnecessary redirects — and each has a distinct, targeted fix rather than a single universal one.