Time to First Byte (TTFB) · Definition & Explanation 2026

Time to First Byte (TTFB) is a performance metric that measures the duration from the user's browser making an HTTP request to the first byte of the response being received. It includes five components:

• •DNS Lookup — Resolving the domain name to an IP address (0–100ms typically, cached locally after first visit).
• •TCP Connection — Establishing the network connection (1 round trip).
• •TLS Negotiation — Establishing the encrypted HTTPS connection (1-2 round trips).
• •Server Processing — The server receiving the request, executing application logic, querying databases, rendering templates, and preparing the response.
• •Response Transit — The first byte traveling from server to browser.

For most sites, server processing is the largest component. A WordPress site running complex database queries on shared hosting might take 800ms just for server processing, before any network transit. The same site on managed hosting with page caching might respond in 50ms.

While not a Core Web Vital, TTFB is reported in CrUX field data and directly constrains LCP. If TTFB is 2 seconds, achieving LCP ≤ 2.5s requires the entire page (including images) to load and render in just 500ms — practically impossible.

TTFB is one of the oldest web performance metrics, predating Core Web Vitals by over a decade.

Key milestones:

• •Pre-2010 — TTFB was the primary metric for web performance, measured by tools like YSlow and early WebPageTest.
• •2012 — Navigation Timing API standardized TTFB measurement in browsers.
• •2020 — Google announces Core Web Vitals but does not include TTFB. However, it remains a CrUX-tracked metric and foundation for LCP.
• •2023 — Google formally recommends TTFB under 800ms and includes it in PageSpeed Insights field data.
• •2025–2026 — TTFB remains a diagnostic metric. Edge computing and CDN improvements continue to lower achievable TTFB globally.

TTFB is measured from request start to first byte arrival via the Navigation Timing API.

Field Data:

• •CrUX / PageSpeed Insights — Real-user TTFB at p75
• •Web Vitals JS library — Custom RUM collection

Lab Data:

• •Chrome DevTools Network panel — Shows TTFB for every request (Waiting/TTFB column)
• •WebPageTest — Detailed TTFB breakdown showing DNS, connect, SSL, and server processing time
• •Lighthouse — Flags server response times over 600ms
• •curl — Command-line TTFB testing: `curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}\n' URL`

1. 1Slow database queries — Unindexed tables, N+1 queries, missing query caching.
2. 2No server-side caching — Every request triggers full application processing (PHP, Node, Python) instead of serving cached HTML.
3. 3Poor hosting — Shared hosting with limited CPU/RAM, oversold servers, slow disk I/O.
4. 4No CDN — Every request travels to the origin server regardless of user location. Users far from the server add 100–500ms of network latency.
5. 5Redirect chains — Multiple 301/302 redirects (http→https→www→final URL) each add a full round trip.
6. 6Heavy server-side processing — Complex template rendering, excessive middleware, synchronous external API calls.