What TTFB Actually Measures
Time to First Byte (TTFB) tracks how long it takes from the start of navigation until the browser receives the first chunk of the HTML response. But the metric includes more than just the time your server spends generating that response.
In Google's Core Web Vitals model, TTFB begins when the user starts navigating and includes:
- Cross-origin redirects
- Connection establishment to the server
- Same-origin redirects
- The actual HTTP request for the HTML document
In a typical request waterfall, the server response time might be only 183 milliseconds — roughly 12% of the total TTFB. Much of the remaining time can go to a cross-origin redirect that must complete before the real HTML request begins, or to the network handshakes needed to connect to the server.
Establishing a connection generally requires three separate round trips:
- DNS: resolving the server IP address
- TCP: opening a reliable connection
- TLS: negotiating encryption
Why Latency Dominates TTFB
Two connections plus two HTTP requests add up quickly. Before the first response byte arrives, the browser and server often exchange data eight times. On a connection with 150 ms round-trip time (RTT), those eight round trips alone take 1.2 seconds — even with a server that answers instantly.
Latency is largely a function of geographic distance between visitor and server. A website hosted in Brazil can show solid TTFB results for visitors in Brazil or on the US East Coast, while users in Europe, Asia, or Australia wait significantly longer. The same page, same server, wildly different numbers depending on where the request originates.
CDNs and Their Effect on TTFB
A Content Delivery Network (CDN) works by distributing server locations globally. Browsers connect to a nearby edge node instead of traveling across the world to the origin server, which drastically cuts the time spent on connection establishment.
By default, the HTML request still reaches your web application. But if the response isn't dynamic, caching it at the edge means the request never travels further than the regional data center. In practice, cached edge responses often produce TTFB under 200 milliseconds from anywhere in the world.
Finding the Right Fix
The right optimization depends on where the TTFB budget is being spent:
- Slow connection setup: deploy a global CDN to shorten the network path
- Slow server response: optimize application code or cache the HTML response
- Redirect delays: avoid chaining redirects and make sure the server returning the redirect responds quickly
Context matters too. Logged-in visitors usually can't be served from cache, so their TTFB may be higher. Ad campaigns that route users through click-tracking servers can add redirects and inflate the metric temporarily.
Measuring Real-World TTFB
Synthetic tests from a single location won't reveal the full picture. Real user monitoring captures TTFB as experienced by actual visitors and lets you break it down by country, login status, referrer domain, or campaign. That separates genuine infrastructure problems from location-specific or traffic-source-specific effects.
Reducing server response time alone is rarely the most impactful change. Because network round trips and redirects often consume most of the TTFB budget, a global CDN — even without edge caching — frequently delivers the largest improvement by eliminating connection setup delays across geographic distances.
