WordPress Slow Server Response Time: How to Fix TTFB (9 Fixes)

Quick answer: Slow server response time means WordPress takes too long to build the HTML before the first byte goes out. Lighthouse flags it when the server takes more than 600 ms, and web.dev rates a TTFB of 0.8 seconds or less as good. The biggest fix is a page cache that actually serves hits. After that, check your hosting and PHP workers, autoloaded options, WP-Cron, external HTTP calls, PHP version, object cache and slow database queries.

This guide is part of my complete guide to fixing common WordPress errors — the hub that maps every common error to its fix.

This post covers the server side only: the time before the first byte. If the HTML arrives fast and the page is still slow because of images, scripts or fonts, that’s a front-end problem, and my guide to a slow-loading WordPress site covers it.

Measure Your Real Server Time With One curl Command

PageSpeed Insights gives you one TTFB number, and that number mixes DNS, the TCP connection, the TLS handshake and the time your server spends building the page. Only the last part is WordPress. curl can split them:

curl -s -o /dev/null -w "dns %{time_namelookup}s connect %{time_connect}s tls %{time_appconnect}s ttfb %{time_starttransfer}s total %{time_total}s\n" https://yoursite.com/some-page/

All curl timings count from the start of the request. So ttfb minus tls is roughly the time between the handshake finishing and the first byte arriving: your server’s work plus one network round trip. That’s the number to watch.

I ran it against one of my own posts on 31 October 2026, three times with the LiteSpeed page cache serving a hit, then three times with the cache bypassed by adding ?nocache= plus a random value to the URL. The test ran from a cloud server through a proxy, which inflates the DNS and connection times, so read the gap between the two rows rather than the absolute values.

A cached page left the server in about 0.2 seconds. The same page built fresh by PHP took 0.46 to 0.63 seconds, two to three times longer, on a small, well-tuned site. On a site with heavy plugins and a bloated database, the uncached number is where things fall apart. Run the command a few times with and without a cache-buster on your own site, and check the x-litespeed-cache, cf-cache-status or similar header to confirm which one you got.

Causes of Slow Server Response, Ranked

Work down this table in order. The first row is the cheapest to check and usually free to fix, and the gap in my test above shows how much it matters.

Fix 1: Make Sure Your Page Cache Actually Hits

The test above is the whole argument: a hit skips PHP and MySQL entirely. Plenty of sites have a caching plugin installed and still miss on most requests, because something tells the cache to step aside. The usual culprits:

• Logged-in users. You see uncached pages whenever you’re logged in to wp-admin. Test in a private window, or you’re measuring the wrong thing.
• Cookies. Cart, consent or A/B-testing plugins that set a cookie on every visitor can make the cache treat every visit as unique.
• Query strings. Ad clicks add ?utm_source=, ?gclid= or ?fbclid=. Unless your cache ignores those parameters, each one is a miss, exactly like the ?nocache= trick I used in the test.

If you don’t have a page cache yet, pick one that matches your server: LiteSpeed Cache on LiteSpeed hosting, a host-level cache on managed WordPress hosts, otherwise a plugin. My comparison of WordPress caching plugins walks through the choice.

Fix 2: Upgrade Hosting or Add PHP Workers

Every uncached request needs a free PHP worker. When all workers are busy, new requests wait in a queue, and that waiting shows up as TTFB even though no code is running. That’s why some sites are fast at 3 a.m. and slow at noon.

Here’s a quick way to tell hosting from code. Run the uncached curl test against a URL that does almost nothing, such as /wp-login.php. If even that page has a high server wait, the server is slow or overloaded and no plugin cleanup will save you. If the login page is fast and your content pages are slow, the problem lives in your theme, plugins or database, so keep going down this list before you pay for a bigger plan.

Fix 3: Trim Autoloaded Options

WordPress loads every autoloaded option from wp_options on every uncached request, whether the page needs it or not. Uninstalled plugins often leave their autoloaded settings behind. Since WordPress 6.6, Site Health warns when the total passes 800 KB (the core default threshold is 800,000 bytes), and the autoload column now uses the values on, auto-on and auto alongside the older yes.

Check the total in phpMyAdmin or with wp db query (change the wp_ prefix if yours differs):

SELECT SUM(LENGTH(option_value)) AS autoload_bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');

Then find the biggest offenders:

SELECT option_name, LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY bytes DESC
LIMIT 15;

Options left by plugins you’ve removed can usually be deleted. For options that belong to active plugins, don’t delete them; set their autoload to off only if you know the plugin reads them on demand, and take a database backup first. Expired transients sitting in the list are safe to clear.

Fix 4: Stop WP-Cron From Running on Page Loads

By default, WordPress checks its scheduled tasks during normal page requests and fires overdue ones in the background. A backlog of heavy jobs (backups, imports, email queues) adds load at random moments, so some visitors get a slow response and others don’t. Move cron to the server: add define( 'DISABLE_WP_CRON', true ); to wp-config.php, then create a real cron job that calls wp-cron.php every five minutes. Never do the first step without the second. I walk through both steps in my missed schedule guide.

Fix 5: Find Slow External HTTP Calls

Some plugins call an outside API while building the page: license checks, social counters, currency rates, remote fonts fetched in PHP. Your TTFB then includes someone else’s server. Install Query Monitor, load a slow page, and open the HTTP API Calls panel. Any call made on a front-end request is a suspect; any call taking hundreds of milliseconds is the culprit. Replace the plugin, or ask its developer to cache the response.

Fix 6: Update PHP

WordPress.org recommends PHP 8.3 or greater. Newer PHP versions generally run WordPress faster, and versions past end-of-life stop getting security fixes. Check your version under Tools → Site Health → Info → Server and switch it in your hosting panel. Test on staging first: old plugins are the usual reason an upgrade breaks a site, and my critical error guide covers what to do if it does.

Fix 7: Add a Persistent Object Cache

WordPress already caches query results in memory, but only for the length of one request. A persistent object cache such as Redis or Memcached keeps those results between requests, so uncached pages and wp-admin stop re-running the same queries. It helps most on WooCommerce, membership and other logged-in-heavy sites where the page cache can’t help. Many hosts offer Redis with one click; turn it on, then connect it with your caching plugin or a Redis object cache plugin.

Fix 8: Find Slow Database Queries With Query Monitor

With Query Monitor active, load the slow page while logged in and open Queries. Sort by time and look at the Component column: it tells you which plugin or theme ran each query. One plugin running a slow query on every page, or a page making hundreds of queries, points straight at what to replace or reconfigure. The same panel is how I’d start on a slow WordPress admin too.

Fix 9: Serve Cached Pages From the Edge

Once the server is fast, distance is what’s left. A visitor on the other side of the world from your server pays several network round trips before the first byte. An edge cache (Cloudflare with HTML caching, or QUIC.cloud on LiteSpeed hosting) stores the cached HTML in data centers close to visitors, so a hit never travels to your origin at all. Do this last: an edge cache in front of a slow, cache-missing origin only hides the problem for pages that happen to be cached.

One more thing after any change: clear the cache layers and rerun the curl test, both hit and miss, so you compare like with like.

Related guide

Best WordPress Caching Plugins in 2026 (Free and Paid)

A cache hit cut server wait to about 0.2 seconds in my test, so picking the right caching plugin is the biggest TTFB decision you’ll make.

Frequently Asked Questions

Wrapping Up

Measure before you change anything: run the curl test, subtract TLS from TTFB, and compare a cache hit with a miss. If the hit is fast and real visitors are slow, they’re missing the cache. If the miss is slow, work down the ranked list, starting with hosting and autoloaded options, and retest after each change.

If you’d rather hand the diagnosis to someone who does this every week, get in touch and I’ll find where your server time is going.

Shahbaz Ali is a senior WordPress and Framer developer with 6+ years of agency experience, specializing in WordPress development, Framer builds, and speed optimization.