PageSpeed Matters
    Speed Audit
    Let's Talk
    PageSpeed Matters
    Book a Call
    Loading Performance · Glossary

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

    Time to First Byte (TTFB) measures the duration from the user's browser making an HTTP request to receiving the first byte of the server's response. It is the foundational loading metric — every millisecond of TTFB directly adds to FCP, LCP, and every other loading metric. While not a Core Web Vital itself, TTFB is tracked in CrUX and Google recommends keeping it under 800ms.

    TTFB encompasses the entire chain from browser to server and back: DNS resolution, TCP connection, TLS handshake, server processing, and response transit. A slow TTFB almost always indicates server-side or infrastructure issues — poor hosting, missing caching, no CDN, or slow database queries.

    According to HTTP Archive data, the median mobile TTFB is approximately 1.3 seconds — well above Google's 800ms recommendation. Sites using CDNs and edge caching routinely achieve TTFB under 100ms for cached content. The gap between optimized and unoptimized TTFB can be 10x or more, making infrastructure optimization one of the highest-impact performance investments.

    This entry covers what TTFB measures, its five components, current thresholds, the best measurement tools, common causes of slow TTFB, and a complete optimization playbook.

    Updated 2026-02-28
    M
    By Matt Suffoletto

    TL;DR — Quick Summary

    TTFB measures the time from the browser's request to receiving the first byte of the response. Good TTFB is under 800ms. It includes DNS + TCP + TLS + server processing + transit time. TTFB is the foundation of all loading metrics — poor TTFB makes good LCP nearly impossible.

    What is Time to First Byte (TTFB)?

    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 Thresholds

    Metric Good Needs Improvement Poor
    TTFB ≤ 800ms 800ms – 1.8s > 1.8s

    Google evaluates the 75th percentile (p75) of real-user field data over a rolling 28-day window.

    History & Evolution

    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.

    How TTFB is Measured

    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`

    Key rule: Field data (CrUX) determines Google rankings. Lab data (Lighthouse, WebPageTest) is for debugging and iteration.

    Common Causes of Poor TTFB Scores

    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.

    Frequently Asked Questions

    No. TTFB is a diagnostic metric tracked in CrUX but not a Core Web Vital. However, it directly constrains LCP (which is a CWV). Google recommends TTFB under 800ms.

    Under 800ms for dynamic content. Under 100ms for cached/static content served from a CDN. Between 800ms and 1.8s needs improvement. Over 1.8s is poor.

    Mobile networks have higher latency (40-100ms per round trip vs 5-20ms on broadband). DNS + TCP + TLS require multiple round trips, each adding mobile latency. A CDN reduces this by serving from nearby edge servers.

    For cached content, yes — dramatically. For uncached dynamic content, a CDN still helps by reducing TLS negotiation time (edge TLS termination) but the origin server still processes the request. Configure CDN caching rules to maximize cache hit rates.

    Server response time is the server processing component of TTFB. TTFB = DNS + TCP + TLS + server response time + transit. You can have good server response time but poor TTFB if DNS/network is slow (use a CDN), or poor server response time but acceptable TTFB if the network is fast.

    Each redirect (301/302) adds a full round trip: browser sends request → server responds with redirect → browser follows new URL. Two redirects (http→https→www→final) can add 300-600ms to TTFB. Eliminate chains by directing to the final URL in one redirect.