Fix Slow TTFB on WordPress: The Exact Order That Works

The fastest way to reduce initial server response time is to work through fixes in order of actual impact: correct PHP version and opcode caching, an object cache like Redis or Memcached, full-page caching that's actually functioning, database query cleanup, then server location relative to your audience. If you've done all five and TTFB is still sitting above 600ms, the software isn't your problem. The server is. That's the part most guides won't tell you, because it doesn't sell a plugin.

How do you measure TTFB properly before touching anything?

Don't start fixing anything until you know your real number, and don't trust a single Lighthouse run to give it to you. Lab tests measure one request from one location at one moment. What matters is field data, the actual experience of real visitors over time, which is what the Chrome UX Report collects and what shows up in your Search Console Core Web Vitals report if your site gets enough traffic to be included.

Pull your TTFB distribution, not just an average. A site can have a good median TTFB and still fail because the 75th percentile is dragged up by cache misses or database spikes. Google's own guidance, laid out in web.dev's TTFB documentation, treats under 200ms as good and above 600ms as poor, and that threshold sits underneath the broader Core Web Vitals scoring that shapes how your pages get treated in search. Test logged out, from a clean cache, and from more than one region if your audience is spread out. Our hosting tools section has speed testing tools that will do this without you needing to build your own script.

Is your PHP version actually the bottleneck?

I still see sites on end-of-life PHP versions because nobody wanted to risk breaking a plugin. That decision is now costing them TTFB on every single request. Older PHP versions are measurably slower at executing WordPress's core, and running without opcache enabled means the server is recompiling PHP on every page load instead of serving it from memory.

Check your PHP version in your hosting control panel today. Anything below the currently supported branch should be upgraded, and opcache should be confirmed on, not assumed on. This is a five-minute check that fixes more slow-server complaints than any plugin I've installed for a client. If you want the full list of what WordPress actually needs to run properly, from PHP to MySQL to cron, we've laid it out in WordPress Server Requirements: PHP, MySQL and Cron.

Do you have an object cache running, or just a page cache?

These get confused constantly, and it matters. A page cache stores the finished HTML. An object cache, typically Redis or Memcached, stores the results of database queries so WordPress doesn't hit MySQL again for the same data on every request. Without one, every logged-in user, every WooCommerce cart, every dynamic widget is triggering fresh database calls that add real milliseconds to TTFB before a single byte of HTML gets generated.

If your host offers Redis or Memcached, turn it on. If they don't offer either, that's a signal worth paying attention to, because it usually means the plan wasn't built for anything beyond a brochure site. I had a client running a membership site on shared hosting with no object cache available at all. Server response time didn't move until we migrated to a host that supported Redis. The plugin she'd installed to "speed things up" had been doing nothing, because there was nothing underneath it to cache into.

Is full-page caching actually configured, or just installed?

Installing a caching plugin and configuring it correctly are two different jobs, and most sites only do the first one. If logged-in users, WooCommerce sessions, or dynamic content are bypassing the cache without you realising it, you're serving uncached pages to a meaningful chunk of your traffic while believing the problem is solved.

Check your cache hit rate, not just whether the plugin is active. Most caching plugins and server-level caches (Varnish, FastCGI cache, LiteSpeed cache) will show you a hit versus miss ratio somewhere in their settings. If misses are high, work out why: exclusion rules that are too broad, cookies being set unnecessarily, or a cache that's being cleared far more often than it needs to be by an aggressive cron job or plugin update cycle.

Are slow database queries and plugin bloat adding hidden overhead?

This is the one people skip, because it requires actually looking at what's running rather than installing something and walking away. A bloated wp_options table full of autoloaded data from abandoned plugins, or a poorly coded plugin firing dozens of queries per page load, will quietly add to server response time regardless of how good your caching setup is.

Install Query Monitor temporarily and look at what's actually slow. You're looking for queries that take an unusually long time, plugins making excessive database calls, and autoloaded options that have crept up over years of installs and uninstalls. I've seen sites drop their server response time meaningfully just from cleaning up autoloaded data nobody remembered was there. This is also where the case for running fewer, better plugins rather than a dozen feature-stuffed ones becomes obvious. We covered why that matters more broadly in Why Simple Hosting Beats Feature-Packed Plans Every Time.

Does your server location actually match where your audience is?

Physical distance between server and visitor adds latency before your application code does anything at all. If your audience is mostly in the UK and your server is in a US data centre because that's where the hosting plan defaulted to, you're paying a distance tax on every single request, regardless of how well-optimised everything else is.

Check where your host's data centres actually are, and pick the one closest to your audience. A CDN helps with static assets and can front dynamic requests too on some setups, but it doesn't fully solve TTFB for dynamic pages if your origin server is still on the wrong continent. If you're choosing a new plan, our hosting directory lets you filter by data centre region, which is more useful than most marketing pages ever admit.

What do you do when none of this moves the needle?

Here's the part most hosting content avoids, because it doesn't lead anywhere profitable for the person writing it. If you've corrected the PHP version, turned on an object cache, confirmed full-page caching is actually hitting, cleaned up the database, and matched server location to audience, and TTFB is still nowhere near the 200ms threshold web.dev treats as good, the honest diagnosis is that you're on oversold shared infrastructure. Too many accounts on one physical server, competing for the same CPU and I/O, will produce a slow, inconsistent TTFB that no amount of plugin tuning fixes, because the bottleneck isn't your software. It's the neighbours.

At that point the answer is to move, not to keep optimising. Look at VPS or managed WordPress plans that guarantee dedicated resources rather than shared capacity you can't see or control. Our best WordPress hosting picks are specifically tested with this in mind, and the Hosting Reliability Index tracks how providers actually perform once the marketing claims are stripped away. If you want the wider context on how hosting quality varies across the industry right now, our state of web hosting report covers it in more depth than any single provider's sales page ever will.

Frequently asked questions

What is a good TTFB for WordPress?

Under 200ms is generally treated as good field data, in line with the thresholds set out in web.dev's TTFB guidance, with anything consistently above 600ms flagged as poor. WordPress sites with no object cache and outdated PHP routinely sit well above that range even before any front-end optimisation is considered.

Does a CDN fix slow TTFB?

A CDN speeds up delivery of static assets and, on some setups, can serve cached HTML from edge locations closer to the visitor, but it does not fix a slow TTFB caused by an unoptimised origin server for dynamic, logged-in, or uncached requests. Treat a CDN as one layer, not the whole fix.

Can I reduce TTFB without changing hosting?

Often, yes. Correcting PHP version, enabling opcache, turning on an object cache, and fixing database bloat regularly bring TTFB down without a migration. The exception is oversold shared hosting, where server-level resource contention caps how far software fixes can take you, regardless of how well configured everything else is.

Is TTFB the same as page load time?

No. TTFB measures how long the server takes to send the first byte of a response, before the browser has even started rendering anything. Page load time includes everything after that: downloading assets, rendering, running JavaScript. A slow TTFB delays everything downstream, which is why it's worth fixing first rather than chasing front-end optimisations on top of a slow origin.