Time to First Byte

Time to First Byte (TTFB) measures the duration from when the browser sends a request for a page to when it receives the first byte of the response. It captures the entire server-side processing pipeline — DNS resolution, TCP connection, TLS negotiation, redirects, and server processing time.

TTFB is a foundational metric. Since every other performance metric (FCP, LCP, INP) can only begin after the first byte arrives, a high TTFB acts as a floor that limits how fast your page can possibly load.

Thresholds

Understanding the Breakdown

When attribution is enabled, FastStats decomposes TTFB into five sequential phases. These phases cover the full journey of the request:

Waiting Duration

Time the browser spends before it can even start the connection. This includes time in the browser's network queue, service worker startup time, and any beforeunload / unload handlers from the previous page.

Cache Duration

Time spent checking the local HTTP cache. A fast cache hit means the response comes from disk rather than the network, resulting in an extremely fast TTFB.

DNS Duration

Time spent resolving the domain name to an IP address. First-time visitors or visitors who haven't accessed the domain recently will incur a DNS lookup.

Connection Duration

Time spent establishing the TCP connection and completing the TLS handshake. For HTTPS sites (which should be all sites), this includes the certificate exchange and cryptographic setup.

Request Duration

Time from when the HTTP request is sent to when the first byte of the response is received. This is the "pure" server processing time — how long your server takes to generate and start sending the response.

TTFB = Waiting + Cache + DNS + Connection + Request

Common Causes of Poor TTFB

No CDN or Edge Caching

Without a CDN, every request travels from the user's browser to your origin server, which may be geographically distant. A user in Tokyo hitting a server in Frankfurt adds 200-300ms of network latency alone.

Fix:

• Deploy a CDN like Cloudflare, Fastly, or AWS CloudFront
• Enable edge caching for static and semi-static pages
• Consider edge rendering (Cloudflare Workers, Vercel Edge Functions) for dynamic content

Slow Server-Side Processing

Complex database queries, unoptimized API calls, or heavy server-side rendering can delay response generation.

Fix:

• Profile server-side performance to identify slow endpoints
• Add caching layers (Redis, Memcached) for frequently accessed data
• Optimize database queries and add appropriate indexes
• Use streaming SSR to send the first bytes while the rest of the page generates

Redirect Chains

Each redirect (301, 302, 307) requires a full additional round-trip. Two redirects can add 200-600ms depending on network conditions.

Fix:

• Audit and eliminate unnecessary redirects
• Ensure users and crawlers access the canonical URL directly
• Use HSTS preloading to avoid the HTTP-to-HTTPS redirect

Unoptimized TLS

Outdated TLS configurations can add unnecessary handshake time.

Fix:

• Enable TLS 1.3 which reduces the handshake to a single round-trip
• Enable OCSP stapling to avoid certificate revocation checks
• Use session resumption to speed up repeat connections

No HTTP/2 or HTTP/3

HTTP/1.1 connections are slower to establish and don't support multiplexing.

Fix:

• Enable HTTP/2 on your server and CDN
• Enable HTTP/3 (QUIC) where supported — it eliminates the TCP handshake entirely for repeat visitors

Overloaded Server

If the server is running at high CPU or memory utilization, response times degrade for all requests.

Fix:

• Scale horizontally (add more instances)
• Scale vertically (increase server resources)
• Implement request queuing and load balancing
• Add auto-scaling based on traffic patterns

TTFB and Other Metrics

TTFB directly impacts every other metric:

Optimizing TTFB is often the highest-leverage performance improvement you can make because it lifts the floor for every other metric.

Interpreting TTFB in FastStats

The metric detail page shows:

• p75 timeline — your TTFB score over time
• Distribution chart — spread of TTFB values across good, needs improvement, and poor
• Five-phase breakdown — waiting, cache, DNS, connection, and request duration visualized as a stacked bar
• Breakdown by page — which routes have the slowest server response
• Geographic breakdown — TTFB varies dramatically by region; a location map highlights where your users experience the most latency
• Cache hit analysis — how often responses are served from cache vs. origin