How to Fix Slow Server Response Time (TTFB)

What this means

Why it matters

How to fix it

1. 1

   Add server-side page caching so pages aren't rebuilt on every request

   Full-page caching is the single biggest TTFB win for most dynamic sites. Instead of running PHP and hitting the database on every visit, the server saves the rendered HTML and serves it in milliseconds on later requests. On WordPress, install a caching plugin such as WP Rocket, LiteSpeed Cache (if your host runs LiteSpeed), or W3 Total Cache, and enable page cache plus object cache. On custom stacks, put a reverse-proxy cache like Varnish or Nginx FastCGI cache in front of your app. The goal is for most page views to come from cache rather than being regenerated.

2. 2

   Put a CDN in front of your site

   A CDN like Cloudflare, Fastly, or Bunny serves content from an edge location close to each visitor, cutting the network round-trip that inflates TTFB for far-away users. Modern CDNs can also cache your full HTML at the edge (Cloudflare's 'Cache Everything' rule or APO for WordPress), so the first byte comes from a nearby edge server instead of your origin. This helps global audiences and offloads your origin. Shopify, Wix, and Squarespace already include a CDN, so a stubbornly high TTFB there points to a heavy theme, too many apps, or an overloaded origin rather than a missing CDN.

3. 3

   Upgrade slow or overloaded hosting

   Cheap shared hosting is the most common cause of a poor TTFB. On a crowded shared server your site competes for CPU with hundreds of others, so response times spike unpredictably. If caching and a CDN still don't get you under 800ms, move to better infrastructure: a quality managed WordPress host (Kinsta, WP Engine, Cloudways, SiteGround's higher tiers) or a VPS or cloud instance with dedicated resources. Confirm you're on a current PHP version (PHP 8.1 or newer), since recent PHP releases execute noticeably faster than older ones.

4. 4

   Optimize the database and slow back-end code

   If your server does real work per request, that work has to be fast. Add indexes to columns used in WHERE and JOIN clauses, and find slow queries with the MySQL slow query log or Query Monitor on WordPress. On WordPress specifically, a bloated wp_options table with hundreds of autoloaded options, or too many active plugins each firing queries, will inflate TTFB, so trim autoloaded data and remove unused plugins. Move slow third-party API calls (weather, currency, social feeds) out of the request path by caching their results or fetching them asynchronously, so a slow external service can't hold up your first byte.

5. 5

   Collapse redirect chains and enable compression

   Every redirect is a full extra round-trip before the real page starts loading, so a chain like http to https to www to final URL can add hundreds of milliseconds. Audit your redirects, collapse chains to a single hop, and make sure the canonical URL (https plus your preferred www or non-www) is the one you link to internally. Separately, enable Brotli or Gzip compression at the server or CDN level so the HTML transfers faster once the server starts sending. Most hosts and every major CDN support this with a single toggle.

6. 6

   Confirm the fix with field data, not one lab test

   After making changes, re-run the audit, but also measure across multiple runs and locations, because a single lab test can be misleading. Use WebPageTest or your browser DevTools Network tab (the 'Waiting for server response' timing on the document request) to measure the origin, then watch the Core Web Vitals report in Google Search Console over the following weeks, which reflects real-user data from the Chrome UX Report. Aim for the 75th percentile of your users to see a TTFB at or under 800ms.

Example

# In the http {} context:
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=SITECACHE:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

server {
    # ...
    location ~ \.php$ {
        fastcgi_pass unix:/run/php/php8.1-fpm.sock;
        include fastcgi_params;

        fastcgi_cache SITECACHE;
        fastcgi_cache_valid 200 60m;        # cache 200 responses for 60 min
        fastcgi_cache_bypass $skip_cache;   # skip for logged-in users, POST, etc.
        fastcgi_no_cache $skip_cache;
        add_header X-Cache $upstream_cache_status;  # HIT/MISS, to verify it works
    }
}

Nginx FastCGI cache that serves cached HTML on repeat requests, cutting TTFB for dynamic PHP sites like WordPress. The cache_path directive goes in the http {} block; the rest goes in your server block. Reload Nginx after editing.

Platform-specific steps

Frequently asked