Time to First Byte

Time to First Byte, commonly abbreviated as TTFB, measures how long it takes for a browser to receive the first byte of data from a server after requesting a page. It is the gap between the moment a user clicks a link or types an address and the instant the very first piece of the response arrives. Everything a visitor eventually sees depends on that first byte showing up, so TTFB acts as an early signal of how responsive a website's infrastructure is. A short TTFB means the server answered quickly, while a long one means the visitor is staring at a blank screen while machines work behind the scenes.

To understand what TTFB captures, it helps to break a request into stages. First the browser resolves the domain name to an address, then it opens a connection and, for secure sites, negotiates encryption. Next it sends the request and waits while the server processes it, perhaps running application code, querying a database, or assembling a page. Finally the server begins streaming the response, and the arrival of that first byte stops the TTFB clock. Because it bundles network travel time and server processing time together, a slow TTFB can point to distant servers, overloaded hardware, heavy backend logic, or missing caching. Content delivery networks, efficient hosting, and cached responses are the usual levers for improving it.

The term itself is descriptive and comes directly from the idea of measuring the first byte of data a server sends. It names exactly what it tracks: how long a browser waits before receiving any response at all. Unlike metrics that describe what a user sees, TTFB describes what the network and server deliver, which makes it a foundational diagnostic rather than a direct experience score.

For a business, TTFB matters because it sets a ceiling on every downstream performance metric. A page cannot start rendering, and certainly cannot reach a fast Largest Contentful Paint, until the server responds. If TTFB is high, even perfectly optimized front-end code will feel slow because the delay happened before the browser could do anything. Search engines crawl faster when servers respond quickly, and users are less likely to abandon pages that begin loading promptly. On large sites, a sluggish TTFB multiplied across thousands of crawled pages can also limit how much of the site gets indexed efficiently.

A common mistake is treating TTFB as the whole story of speed, when in reality it is only the opening chapter. A site can have an excellent TTFB and still feel slow if render-blocking resources or bloated scripts delay what the user sees, and conversely a site with heavy backend logic can undermine an otherwise lean front end. Another frequent error is ignoring geography: a server located far from visitors adds network latency that no amount of code tuning will fix, which is where a content delivery network earns its keep. TTFB relates closely to First Contentful Paint and Largest Contentful Paint, since both of those cannot improve past the limit that server response time imposes. Treating it as one link in a chain, rather than a standalone target, leads to better overall results.