Web Performance & Standards
What is TTFB?
TTFB, Time to First Byte, is a web performance metric that measures the duration from when a browser sends an HTTP request to when it receives the first byte of the server’s response. TTFB captures the combined latency of the network connection establishment, server processing time, and network transmission time for the response to begin arriving at the client. It is the foundational server-side performance metric, the time the browser spends waiting before any response content begins to arrive.
TTFB is measured in milliseconds. A request sent at time 0 that receives its first response byte at time 200ms has a TTFB of 200ms. Everything that happens to produce that response, DNS resolution, TCP handshake, TLS negotiation, server processing, and the time for the first byte to travel from server to browser, is captured in this single measurement.
TTFB is the starting point for all other performance metrics, no content can be rendered, no resources can begin loading, and no user interactions can occur until the browser has received the first byte of the response and begun parsing it. A page with excellent Largest Contentful Paint cannot be achieved with poor TTFB, LCP requires content to be downloaded, parsed, and rendered, and that sequence cannot begin before the first byte arrives. Improving TTFB is therefore one of the highest-leverage page speed optimisations available, the improvement propagates through all downstream metrics.
For redirect management TTFB is the key metric demonstrating the performance cost of redirects, each redirect response adds its own TTFB before the destination page’s TTFB begins. A single redirect with 300ms TTFB followed by a destination page with 200ms TTFB means the browser waits 500ms before receiving any destination page content, 300ms more than if the redirect did not exist. Edge-executed redirects, returning redirect responses from infrastructure near the user, reduce redirect TTFB to tens of milliseconds rather than hundreds.
Components of TTFB
TTFB is not a single delay but the sum of several sequential components, each arising from a different stage of the connection establishment and response generation process.
DNS resolution time: the time to resolve the domain name to an IP address through the DNS system. An uncached DNS lookup traverses the resolution hierarchy, resolver to root nameserver to TLD nameserver to authoritative nameserver, accumulating latency at each step. Cached DNS lookups are served from the resolver’s cache in milliseconds. DNS resolution adds 0-150ms to TTFB depending on whether the DNS is cached and how fast the authoritative nameserver responds.
DNS resolution time is a one-time cost per domain per session, subsequent requests to the same domain in the same browsing session use the cached DNS result. For redirect chains where each hop goes to a different domain, common in affiliate redirect chains and multi-step campaign redirects, each new domain incurs its own DNS resolution cost.
TCP connection time: the time to establish a TCP connection through the three-way handshake, SYN, SYN-ACK, ACK. TCP connection establishment requires 1.5 round trips, one full round trip for SYN/SYN-ACK plus half a round trip for ACK. On a 100ms round-trip-time connection TCP establishment adds approximately 150ms to TTFB.
Persistent connections, HTTP keep-alive, reuse established TCP connections for multiple requests, eliminating connection establishment overhead for subsequent requests on the same connection. Browser connection pools maintain multiple connections per domain, subsequent requests to the same domain may find an available persistent connection and skip TCP establishment.
TLS handshake time: the time to complete the TLS handshake for HTTPS connections. TLS 1.3, the current standard, requires one round trip for the handshake, approximately 100ms on a 100ms RTT connection. TLS 1.2 required two round trips, 200ms. TLS session resumption reduces subsequent handshake overhead, returning visitors with a cached TLS session can resume with minimal handshake overhead.
TLS handshake time is eliminated for persistent connections, already-established HTTPS connections do not require a new handshake for each request. First connections to new domains, as occurs in redirect chains, always incur the full TCP and TLS overhead.
Server processing time: the time the server spends receiving the request, executing application logic, and beginning to transmit the response. Server processing time includes database query execution, application code execution, template rendering, cache lookups, and all other server-side computation required to generate the response.
Server processing time is the component of TTFB most directly under the website operator’s control, optimising application code, improving database query performance, implementing server-side caching, and upgrading to faster infrastructure all reduce server processing time. For redirect responses server processing time is minimal, redirect rules execute in microseconds to milliseconds, the dominant TTFB component for redirects is network latency rather than server processing.
Network transmission time for first byte: the time for the first byte of the response to travel from the server to the browser after the server begins transmitting. For small responses, like redirect responses, this is approximately half of one round-trip time. For the first byte of a large HTML document the server may begin transmitting immediately, the time for the first byte to arrive is primarily network propagation delay.
TTFB thresholds and benchmarks
Google provides TTFB guidance as part of its page experience assessment, though TTFB is not a direct Core Web Vitals metric it influences Largest Contentful Paint significantly.
Google’s TTFB guidance: Good, under 800 milliseconds. Needs Improvement, 800 milliseconds to 1.8 seconds. Poor, over 1.8 seconds.
These thresholds reflect total TTFB including all components, network and server. A 200ms server processing time with 300ms round-trip time produces approximately 500ms TTFB, within the good range. The same 200ms server processing time with 600ms round-trip time produces approximately 900ms TTFB, in the needs improvement range, demonstrating how geographic distance between user and server affects TTFB independently of server performance.
Industry benchmarks: typical production TTFB values for well-optimised sites:
Cached CDN edge response, 10-50ms. Content served directly from CDN edge cache without origin involvement, the fastest achievable TTFB. Edge function response, 20-80ms. Simple logic executed at edge nodes, redirect responses from edge-deployed redirect platforms. CDN-proxied origin response, 100-300ms. Cache miss, CDN forwards to origin and returns the response. Direct origin response, 100-500ms. Request served directly from origin without CDN, highly dependent on user-to-origin geographic distance.
TTFB and redirects
The relationship between TTFB and redirects is direct and significant, redirects multiply the TTFB cost by adding additional request-response cycles before the destination page’s TTFB begins.
Redirect TTFB accumulation: a redirect response has its own TTFB, the time from the browser sending the redirect source request to receiving the 301 or 302 response. This redirect TTFB is added to the destination page’s TTFB, the total delay before destination page content begins arriving is the sum of all redirect TTFBs plus the destination page TTFB.
For a single redirect: Total wait before destination content = Redirect TTFB + Destination TTFB
For a two-hop redirect chain: Total wait = Redirect 1 TTFB + Redirect 2 TTFB + Destination TTFB
Each redirect adds its full TTFB, including any new connection establishment for cross-domain redirects. On a mobile connection with 300ms RTT a three-hop redirect chain where each hop requires a new connection adds approximately 1.5 seconds of redirect latency, on top of the destination page’s own TTFB.
Same-domain vs cross-domain redirect TTFB: same-domain redirects, HTTP to HTTPS, www to non-www, trailing slash normalisation, can reuse the existing TCP and TLS connection. The redirect TTFB consists primarily of server processing time, typically 1-20ms, and half-RTT response transmission. Cross-domain redirects, changing the domain entirely, require new DNS resolution, new TCP connection, and new TLS handshake for each hop. Cross-domain redirect TTFB is dominated by connection establishment overhead rather than server processing.
Redirect chains and cumulative TTFB: the TTFB impact of redirect chains is the reason that collapsing chains to direct single-hop redirects is a high-priority performance optimisation. A three-hop chain where the first two hops are cross-domain redirects with 300ms TTFB each adds 600ms before the destination, adding 600ms to LCP before any destination page content begins loading. A direct single-hop redirect from source to destination eliminates the two intermediate hops, saving 600ms from LCP.
Edge redirect execution and TTFB: redirect management platforms that execute redirect rules at edge nodes near users achieve dramatically lower redirect TTFB than origin-based redirect execution. An edge node 20ms from the user returns a redirect response with approximately 20-30ms TTFB, the network propagation component. The same redirect processed at an origin 200ms from the user has approximately 200-250ms TTFB. For users far from the origin server the TTFB advantage of edge execution is the full round-trip difference, potentially 400ms or more for intercontinental connections.
Measuring TTFB
Several tools measure TTFB, each providing different perspectives on server response performance.
Chrome DevTools Network panel: the browser’s built-in network analysis tool provides per-request TTFB measurements. Opening DevTools, F12, navigating to the Network panel, and hovering over any request shows a timing breakdown, including TTFB, for that specific request. The waterfall chart shows all requests in sequence, redirect chains are visible as sequential entries each showing their individual TTFB.
Examining a redirect chain in DevTools: The first entry, the redirect source URL, shows a small response with a 3xx status code and its TTFB. Subsequent entries, intermediate redirects, each show their own TTFB. The final entry, the destination page, shows its TTFB, which begins only after all preceding entries complete.
Google PageSpeed Insights: provides TTFB data from both Chrome User Experience Report field data and Lighthouse lab measurements. Field data represents real user TTFB across many visits, more representative than single-point lab measurements. Lab measurements provide a controlled baseline.
WebPageTest: advanced performance testing with detailed TTFB analysis from multiple geographic locations. Testing from multiple locations reveals geographic TTFB variation, demonstrating the benefit of CDN deployment for reducing TTFB for distant users. Waterfall charts show individual request timing including DNS, connection, TLS, wait, TTFB, and download phases.
curl: command-line HTTP client provides TTFB measurement:
The time_starttransfer value is TTFB, the time from the start of the request to when the first byte of the response begins arriving. This approach enables scripted TTFB monitoring, measuring TTFB from a specific location on a regular schedule.
Improving TTFB
TTFB improvement strategies address the different components, network latency and server processing time.
CDN deployment: the highest-impact TTFB improvement for geographically distributed audiences. CDN edge servers serve cached content from locations near users, reducing network latency from the user-to-origin distance to the user-to-edge distance. TTFB for cached CDN responses is typically 10-50ms regardless of origin server location, dramatically lower than origin TTFB for distant users.
Edge computing for dynamic content: edge functions execute application logic at edge nodes, providing CDN-level TTFB for dynamic responses that cannot be cached. A redirect rule evaluated at an edge node achieves 20-50ms TTFB, equivalent to a cached CDN response, regardless of origin location.
Server-side caching: caching frequently requested dynamic responses at the application level, using Redis, Memcached, or in-memory caching, eliminates database queries for cached content. A response served from application cache has near-zero server processing time, only network latency affects TTFB.
Database optimisation: slow database queries are a common source of high server processing time. Query optimisation, adding appropriate indexes, rewriting inefficient queries, eliminating N+1 query patterns, directly reduces the server processing component of TTFB.
Upgrading server infrastructure: more powerful servers with faster CPUs, more RAM, and faster storage process requests more quickly, reducing server processing time. Moving to faster hosting, dedicated servers, optimised cloud instances, provides immediate server processing time improvements.
HTTP/2 and HTTP/3: multiplexed connections reduce connection establishment overhead for subsequent requests, and HTTP/3’s QUIC transport combines TCP and TLS establishment into a single round trip, reducing first-connection TTFB by one round trip compared to TLS 1.3 over TCP.