Skip to the journal
Search Engine Optimization Directory

Time to First Byte (TTFB): Server Response Time and How to Reduce It

  • Filed November 10, 2026
  • Page speed and Core Web Vitals, guide 8 of 10

Time to First Byte is the time from when a user starts navigating to a page until the browser receives the first byte of the HTML response. It is not the same as page speed: a page can have a fast TTFB and still be slow because of heavy images or scripts, and a slow TTFB delays everything that follows. web.dev describes good TTFB values as 0.8 seconds or less and poor values as greater than 1.8 seconds, and notes that TTFB is not a Core Web Vitals metric (web.dev on TTFB). Its importance comes from its place at the start of the chain: in web.dev’s LCP breakdown guidelines, TTFB accounts for roughly 40 percent of a well-optimized LCP (optimizing LCP).

What TTFB includes

web.dev lists the phases that add up to TTFB:

  1. redirect time;
  2. service worker startup time, if applicable;
  3. DNS lookup;
  4. connection and TLS negotiation;
  5. the request, up until the first byte of the response arrives.

The last phase includes the server’s own work: routing, database queries, rendering templates, calling APIs. A slow TTFB can come from any of the five, and the fix differs for each.

A TTFB diagnostic decision tree

1. Is TTFB slow in field data, lab data, or both?

  • Only in the field: suspect geography (distant users), network conditions or redirects from external links. Go to 2.
  • In the lab too: suspect the server. Go to 4.

2. Do users arrive through redirects?

  • Check campaign links and ads: a redirect from http:// to https:// and then to www adds two round trips before the HTML request starts. Point links at final URLs; collapse redirects into one hop.

3. Are slow users far from the origin?

  • web.dev notes that users located far from the origin server may still experience high TTFB even when the server is fast, and that CDNs can cache content at edge servers closer to visitors (optimizing TTFB). Compare TTFB by country in real-user data. If distance dominates, a CDN that caches HTML (where appropriate) or serves from edge locations is the fix.

4. Is the server’s processing time long?

  • Instrument the backend. web.dev recommends the Server-Timing header to measure distinct backend processes; its values appear in the browser’s Navigation Timing data, so they can be collected from real users.
Server-Timing: db;dur=420, render;dur=180, cache;desc="MISS"

The header travels with every response, so anyone who loads the page can read it; keep its names and descriptions free of internal details you would not publish.

  • If database time dominates: add indexes, cache query results, reduce queries per page.
  • If rendering dominates: cache rendered HTML or page fragments; reduce template complexity.
  • If external API calls dominate: cache responses, call them asynchronously, or move them out of the critical path.

5. Is the HTML cacheable?

  • Pages that are the same for all users (articles, category pages, landing pages) can be cached at the CDN or in a server-side cache. web.dev notes CDN caching requires appropriate Cache-Control headers and is not appropriate for personalized content, and that caching raises the possibility of serving stale content.
  • stale-while-revalidate lets a cache serve a slightly stale response while it fetches a fresh one in the background. web.dev notes it should be paired with max-age, which defines when a response becomes stale (stale-while-revalidate).

6. Is connection setup slow?

  • Check DNS provider response times, TLS configuration and whether connections are reused. web.dev notes CDN providers usually offer fast DNS resolution.

Measuring TTFB

  • Field: PageSpeed Insights and the Chrome UX Report show TTFB for real users. Real-user monitoring can break it down by country, device and page type.
  • Lab: Chrome DevTools’ Network panel shows “Waiting for server response” for the document request.
  • Server: application performance monitoring and Server-Timing show where server time goes.

Measure from several locations. A server in one region can look fast from a nearby monitor and slow for distant users.

TTFB and search engines

Two separate effects:

  • Users: TTFB delays LCP and every other paint metric, so a slow server shows up in Core Web Vitals.
  • Crawling: Google’s crawl budget guide says that when a site slows down and response times get longer, the crawl capacity limit goes down and Google crawls less (Google’s crawl budget guide). A slow server can slow the discovery and refresh of pages on large sites.

Cutting a WordPress site’s TTFB

In a hypothetical case, a WordPress site has a field TTFB of 2.4 seconds at the 75th percentile.

  • Lab: TTFB 1.9 seconds from a nearby location, so the server is slow even without distance.
  • Server-Timing: database 1.3 seconds; a plugin runs 140 queries per page view.
  • Changes: enable full-page caching for anonymous visitors; add an object cache for database queries; replace the plugin generating repeated queries.
  • Lab check after the changes (illustrative figures): TTFB 0.3 seconds for cached pages, 0.9 seconds for uncached.
  • Field check: after the CrUX 28-day window, field TTFB and LCP for the main templates are compared with the baseline.
  • Still open: logged-in users still receive uncached pages; personalized pages need separate optimization.

What TTFB does not tell you

  • How fast the page renders after the first byte.
  • Whether images, fonts or scripts are slow.
  • Whether interactions are responsive.

Keep TTFB in its place: an early, important link in the chain that determines how fast everything else can start.