Time to First Byte (TTFB)

Time to First Byte (TTFB) is the time elapsed between a browser sending a request and receiving the first byte of the response. It captures network latency, server processing time, and any redirect chains along the way. TTFB is not officially one of the Core Web Vitals, but Google treats it as a foundational input — every downstream metric, including Largest Contentful Paint (LCP), depends on TTFB.

Google's recommended thresholds: Good is under 800ms, Needs Improvement is 800–1800ms, Poor is over 1800ms. For competitive performance, aim well below 500ms at the 75th percentile.

TTFB has three primary components. First, network latency: DNS lookup, TCP handshake, TLS negotiation, and the round-trip distance to the origin server. Second, server processing: how long the back-end takes to generate the response (database queries, template rendering, business logic). Third, transit: the time for the first byte to traverse the network back to the client.

The biggest wins come from caching and edge delivery. A page served from a CDN edge cache often has TTFB under 100ms regardless of the origin server's speed, because the response is already pre-rendered close to the user. Static assets (CSS, JS, images) should always be served from a CDN. Dynamic HTML can be edge-cached on a per-route or per-user basis with appropriate cache-control headers.

For dynamic pages that genuinely cannot be cached, back-end optimisation matters. Common causes of slow TTFB: N+1 database queries, missing indexes, synchronous external API calls in the request path, heavy template rendering, and lack of server-side response compression. Profile each request with APM tooling (New Relic, Datadog, Sentry, or open-source equivalents) to identify the dominant cost.

Redirect chains compound TTFB linearly — each hop adds a round trip. Audit common entry points (homepage, marketing landing pages, brand searches) for HTTPS, www-vs-non-www, and trailing-slash redirect chains and consolidate them to a single hop.

TTFB also affects Crawl Budget: when Googlebot detects slow response times, it backs off to avoid degrading the site for human users. A faster origin means more pages crawled per day, which matters for large or frequently updated sites.