Slow TTFB: Fixing Time to First Byte

What TTFB includes

TTFB is measured from the moment the browser starts navigating to the page until the first byte of the response arrives. That single number hides several separate waits, and each has a different fix.

web.dev suggests about 0.8 seconds or less as a rough guide to a good TTFB, and treats more than 1.8 seconds as poor. Because TTFB is a diagnostic rather than a Core Web Vital, there is no pass or fail in Search Console for it. What matters is how much of your LCP budget of 2.5 seconds it uses up. If the HTML takes 1.5 seconds to arrive on a phone, only a second is left for the stylesheets, fonts and hero image.

How to measure it properly

Field data first

The Core Web Vitals checker shows field data from the Chrome UX Report, which includes TTFB alongside the three Core Web Vitals, and a lab test from one location. Real-user TTFB is often much worse than a test from a data centre, because visitors are on mobile networks, further away from your server and sometimes arriving through redirects from ads or emails.

From the command line

curl can split one request into its parts. Run it several times, since the first request after a quiet spell is often slower.

curl -o /dev/null -s -w "dns      %{time_namelookup}\nconnect  %{time_connect}\ntls      %{time_appconnect}\nttfb     %{time_starttransfer}\ntotal    %{time_total}\nredirects %{num_redirects}\n" -L https://www.example.co.uk/

The figures are cumulative seconds from the start. Subtract tls from ttfb to get the time the server spent building the page. If that gap is large, the server is the problem. If connect and tls are large, distance or network set-up is.

In the browser

In the DevTools Network panel, click the HTML document and open Timing. "Waiting for server response" is the server processing part. For your own real-user data, the Navigation Timing API gives the same breakdown:

const [nav] = performance.getEntriesByType('navigation');
console.table({
  redirect: Math.round(nav.redirectEnd - nav.redirectStart),
  dns:      Math.round(nav.domainLookupEnd - nav.domainLookupStart),
  connect:  Math.round(nav.connectEnd - nav.connectStart),
  server:   Math.round(nav.responseStart - nav.requestStart),
  ttfb:     Math.round(nav.responseStart)
});

Redirect time is only reported for same-origin redirects, so a redirect from another domain, such as an ad click tracker, shows as a gap rather than a number.

Ask the server where it spent the time

The Server-Timing response header lets your application report its own timings, which DevTools shows in the Timing tab for the request.

Server-Timing: db;dur=412;desc="Database", tpl;dur=95;desc="Templates", cache;desc="MISS"

Even a rough version, timing the database and the template, makes it obvious which part of the server needs attention.

The fix, step by step

Caching HTML without breaking the site

Full-page caching gives the biggest TTFB improvement for most sites, because serving a stored file takes a small fraction of the time needed to run the application and query the database. Done carelessly it also causes the most embarrassing bugs, such as one visitor seeing another's basket.

What can and cannot be cached

• Cache: home, category, product, article, service and landing pages for logged-out visitors.
• Do not cache: basket, checkout, account, order confirmation, admin, and any response that sets a session cookie.
• Handle separately: small personal parts of a cached page, such as a basket count or "Hello, Sam", can be loaded with a small request after the page arrives, so the page itself stays cacheable.

A CDN header for HTML

This tells shared caches such as a CDN to keep the page for ten minutes and serve a slightly stale copy for up to a minute while fetching a fresh one in the background, while browsers always revalidate:

Cache-Control: public, max-age=0, s-maxage=600, stale-while-revalidate=60

Support for these directives varies between CDNs, and some need HTML caching switched on as a separate setting, so check your provider's documentation.

An nginx page cache for a PHP site

fastcgi_cache_path /var/cache/nginx/pages levels=1:2 keys_zone=PAGES:50m inactive=60m;

map $http_cookie $skip_cache {
  default 0;
  ~wordpress_logged_in 1;
  ~woocommerce_items_in_cart 1;
}

server {
  location ~ \.php$ {
    fastcgi_cache PAGES;
    fastcgi_cache_key "$scheme$request_method$host$uri";
    fastcgi_cache_valid 200 301 10m;
    fastcgi_cache_use_stale error timeout updating http_500 http_503;
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;
    add_header X-Cache $upstream_cache_status;
    # ... your usual fastcgi_pass and params
  }
}

Using $uri instead of $request_uri in the key ignores the whole query string, which stops tracking parameters from creating cache misses. Only do that if none of your cacheable pages use query strings for real content, such as filters or pagination; otherwise strip only the marketing parameters.

Platform notes

WordPress and WooCommerce

Uncached WordPress builds every page with PHP and many database queries, so a page cache usually makes the largest single difference. Many managed hosts include one; otherwise a caching plugin or a server-level cache does the job. Add a persistent object cache for logged-in and WooCommerce traffic, and review plugins that run database queries on every request. The WordPress Core Web Vitals guide covers hosting and caching choices.

Shopify and other hosted platforms

You cannot change the server, and pages are served through the platform's own CDN. Slow TTFB here usually comes from redirects, from very complex theme templates with many loops over large collections, or from visitors arriving through tracking links. Simplify heavy sections and make sure links point at final URLs.

Next.js, Nuxt and other frameworks

Pages rendered on the server for every request are only as fast as their data fetching. Where the content is the same for everyone, pre-render it at build time or use incremental regeneration so the HTML is served from a cache, and stream the page so the first bytes are sent before slow data arrives. Serverless functions that have not run for a while can be slow on the first request; see the Next.js and Nuxt guide.

Static sites

Static HTML served from a CDN is usually fast already. If TTFB is still slow, check for redirects, a CDN that is not caching HTML, or a CDN that sends every request back to a distant origin server.

Edge cases

• Fast for you, slow for visitors. You probably have a warm cache and live near the server. Test from a clean browser, from another network and from the country your visitors are in.
• Slow only on the first visit after a quiet period. Caches expire and serverless functions go cold. Longer cache lifetimes with purge on update, and stale-while-revalidate, keep a copy ready.
• Slow only from ads. Paid clicks carry tracking parameters and sometimes go through the ad platform's redirects. Check the cache ignores the parameters and the destination URL is final.
• Slow for UK visitors on a host abroad. Distance adds to every connection. A CDN in front of the site, or hosting nearer your audience, helps more than any code change.
• 103 Early Hints. Some CDNs can send an early response listing key files to preload while the server is still building the page. It does not reduce TTFB itself, but it lets the browser start on stylesheets and fonts sooner, which can help LCP.

Keeping TTFB low

• Watch the cache hit rate. A falling hit rate after a new plugin, cookie or campaign is an early warning.
• Keep links final. Update internal links, canonicals and sitemaps whenever URLs change, so redirects stay rare.
• Log slow queries continuously and review them after each release.
• Test TTFB after hosting or DNS changes, and after adding anything that runs on every request.
• Keep Server-Timing headers in production so you can see server time for any request in DevTools.

For the other parts of page speed, see redirect chains and the page speed fixes.