Time to First Byte (TTFB)

Time to First Byte measures the interval between a browser requesting a resource and receiving the first byte of the response. It aggregates several distinct phases: redirects, DNS resolution, connection establishment, TLS negotiation, the request itself, and the server's processing time before it begins responding. Because everything else in page loading depends on this response arriving, it functions as a floor beneath every downstream loading metric.

Its diagnostic value comes from that position in the sequence. A page with a slow largest contentful paint and a fast first byte has a front-end problem, in asset delivery, rendering, or blocking resources. The same page with a slow first byte has a back-end or network problem, and no amount of image optimization or script deferral will fix it, because the browser has not yet received anything to work with. Establishing which of these applies is the first step in any serious performance investigation.

The contributing causes divide into network and server categories. On the network side, geographic distance between the visitor and the origin server adds unavoidable latency, redirect chains add a full round trip each, and connection and TLS negotiation add further round trips for new connections. On the server side, slow application code, unindexed or inefficient database queries, calls to external services made synchronously during the request, absent or ineffective caching, and resource contention on shared hosting are the usual causes.

The remedies differ accordingly. Content delivery networks address distance by serving from locations near the visitor, and can serve cacheable responses entirely from the edge without contacting the origin. Caching at multiple layers, including full-page, fragment, object, and database query caching, removes repeated work. Eliminating redirect chains removes whole round trips, which is frequently the single largest available improvement on sites with legacy URL structures. Modern protocols and connection reuse reduce negotiation overhead. On the application side, query optimization and moving non-essential work out of the request path address the server component.

Measurement should distinguish between cached and uncached responses, and between first and repeat visits, since these can differ by an order of magnitude and an average conceals both. Field data segmented by geography and connection type is more informative than a single figure, because a site with acceptable overall numbers may be serving one market very poorly. Testing from the location where the site is hosted, which is the common default, systematically underestimates what distant visitors experience.

Cache hit rate is the single most useful diagnostic when investigating this metric on a site behind a content delivery network, and it is frequently poor for reasons that are easy to correct. Responses marked uncacheable by default, cache keys fragmented by tracking parameters or unnecessary headers, and short expiry times all cause requests to reach the origin that need not have. Measuring the proportion of requests served from the edge, and examining what distinguishes the misses, typically identifies a small number of configuration decisions responsible for most of them. Improving that proportion reduces both latency for visitors and load on the origin, which improves the responses that genuinely must be generated.

Because improvement usually requires changes to infrastructure, caching strategy, or application code rather than to front-end assets, this measure is where performance work most often crosses from the presentation layer into engineering. In practice it is addressed jointly by web performance and product development, and it is frequently the constraint that must be resolved first, since front-end optimization applied on top of a slow origin produces disappointing results that are then wrongly attributed to the optimization work.