TTFB · Time to First Byte — Complete Guide

Time to First Byte measures the time between a browser sending an HTTP request for a page and receiving the first byte of the HTML response. It encompasses three sequential phases: DNS lookup time (resolving the domain to an IP address), connection time (TCP handshake plus TLS negotiation for HTTPS), and server processing time (generating and beginning to send the HTML response).

Google recommends a TTFB under 800ms for a good LCP score. TTFB itself is not a Core Web Vital and does not directly affect page ranking — but because it determines when the browser can begin discovering and loading all other page resources, high TTFB raises LCP proportionally.

LCP cannot be faster than TTFB. The browser cannot begin downloading any resource — images, CSS, fonts — until it has parsed the HTML. It cannot parse the HTML until the first byte arrives. For a page with a 2-second TTFB, LCP cannot possibly be under 2 seconds regardless of how well-optimised the images and CSS are.

Google's analysis of HTTP Archive field data consistently shows TTFB as the largest single contributor to LCP time on pages that fail the Core Web Vitals assessment — accounting for 40–60% of total LCP time on slow pages. Fixing TTFB first provides the highest leverage before optimising other LCP sub-parts.

• No CDN — single origin server. A user in Mumbai requesting a page from a server in London adds 140ms of round-trip latency before a single byte is received. Multiply by the TCP handshake (3 round trips) and TLS negotiation (1–2 round trips) and the connection overhead alone exceeds 600ms.
• Uncached dynamic pages. CMS platforms generating pages by querying a database on every request can take 500ms–3s of server processing time per request under load.
• Slow database queries. Missing indexes, N+1 query patterns, and unoptimised joins on large tables directly extend server processing time.
• Inadequate server resources. CPU throttling on shared hosting under load, insufficient RAM causing swap usage, and connection pool exhaustion all increase server processing time.
• Synchronous external API calls. Server-side code that waits for third-party API responses (payment processors, personalisation engines, recommendation systems) before rendering the page adds the API's latency to TTFB.
• Uncompressed responses. Not enabling Brotli or gzip compression increases response size and transfer time — affecting Time to Last Byte even if TTFB itself is low.

A Content Delivery Network is the highest single-impact TTFB fix for most sites. CDNs cache your pages and assets at edge servers in dozens to hundreds of geographic locations. When a cached page exists at the nearest edge, a user's request is served from a server typically under 20ms away rather than a distant origin server.

# For pages that can be cached at the CDN edge
Cache-Control: public, max-age=3600, stale-while-revalidate=86400

# For user-specific pages (shopping cart, account pages)
Cache-Control: private, no-store

# Static assets with content hash in filename
# e.g. /styles/main.a3f4b2c1.css
Cache-Control: public, max-age=31536000, immutable

When a CDN cache miss occurs — for user-specific pages or cache-busted requests — the origin server must generate the response. Server-side caching keeps generated HTML in memory so repeat requests do not re-execute database queries and template rendering.

For pages that cannot be fully cached (personalised content, live data), server and database optimisation directly reduces the processing component of TTFB.

• Database indexes. Ensure columns used in WHERE, JOIN, and ORDER BY clauses are indexed. A single missing index on a high-traffic query can increase query time from milliseconds to seconds. Use EXPLAIN in MySQL/PostgreSQL to identify full table scans.
• Eliminate N+1 queries. The N+1 pattern (one query to fetch a list, then one query per item to fetch related data) is one of the most common database performance problems. Use eager loading (JOINs or ORM includes) to fetch all required data in a single query.
• Connection pooling. Establishing a new database connection for every HTTP request adds 20–100ms overhead. Use connection pooling (PgBouncer for PostgreSQL, MySQL connection pool) to reuse existing connections.
• Move to faster hosting. Shared hosting CPU throttling produces high and unpredictable TTFB under even moderate load. Moving to a VPS, managed cloud instance, or dedicated server with adequate CPU and RAM is often necessary for consistently good TTFB.

HTTP 103 Early Hints is a response status code that allows the server to send Link: rel=preload headers to the browser before the full 200 response is ready. While the server is still processing the page request — querying the database, rendering templates — the browser can begin fetching critical resources (the LCP image, the main CSS file, key fonts) in parallel.

The practical effect: resources that previously had to wait for TTFB before downloading can start downloading during server processing time, overlapping Phase 1 (TTFB) and Phase 2 (resource load delay) of LCP simultaneously.

HTTP/1.1 103 Early Hints
Link: </styles/main.css>; rel=preload; as=style
Link: </images/hero.webp>; rel=preload; as=image; fetchpriority=high

HTTP/1.1 200 OK
Content-Type: text/html
...actual HTML response...

Chrome has supported Early Hints since version 103. Server-side support: Cloudflare Workers and Pages support Early Hints natively; Apache and Nginx require explicit configuration; most modern CDNs (Fastly, Akamai) support them at the edge.

Authentic Sources