How to Reduce WordPress Server Response Time

When Lighthouse or PageSpeed Insights tells you to "Reduce initial server response time," it is measuring exactly one thing: how long your server takes to hand back the first byte of the HTML document. That is Time to First Byte (TTFB), and it is a server-side problem, not a front-end one. Minifying CSS, lazy-loading images, and deferring JavaScript are all worthwhile, but none of them move this number. If your page sits idle for 1.2 seconds before a single byte arrives, no amount of asset optimization will save your Largest Contentful Paint.

This article stays strictly on the part of the request that happens before the browser receives anything: the PHP execution, the database queries, and the network hop to your origin. Get those right and everything downstream gets faster for free.

What counts as a good TTFB

Two numbers are worth memorizing. Lighthouse flags the audit as failing when the document response time exceeds 600 ms. Separately, the Core Web Vitals field-data guidance treats a TTFB under 800 ms as "good." The 600 ms Lighthouse bar is deliberately stricter, because server response is usually the largest single chunk of that 800 ms budget. In practice, aim for an origin TTFB of around 200 ms on cache hits. Anything consistently above 600 ms means the server is doing real work on every request that it should not be.

Measure it before you touch anything. Open Chrome DevTools, go to the Network tab, click the document request, and read the "Waiting for server response" timing. Or run a one-liner from your terminal:

• curl -w "TTFB: %{time_starttransfer}s\n" -o /dev/null -s https://yoursite.com/
• WebPageTest for a test from a specific geographic location, which exposes whether distance to your origin is the problem.

Run the test logged out, then again logged in. The two numbers are usually wildly different, and that gap tells you which fix matters most.

Full-page caching: the single biggest lever

By far the largest TTFB win on a WordPress site is serving a pre-built HTML page so that PHP and MySQL never run at all. On a default install, every page view boots WordPress, executes dozens of plugin hooks, and fires database queries before producing a byte of output. Full-page caching does that work once, stores the result, and serves the static copy to everyone else in single-digit milliseconds.

Your options, roughly in order of how much they remove from the request path:

• Server-level caching — Nginx FastCGI cache or Varnish, configured by your host. This is the fastest because the request never reaches PHP. Managed hosts like Kinsta, WP Engine, and Rocket.net run this for you automatically.
• LiteSpeed Cache (LSCache) — excellent and free, but only works if your server actually runs LiteSpeed or OpenLiteSpeed. On the right stack it is hard to beat.
• Plugin-level page caching — WP Rocket, FlyingPress, or W3 Total Cache generate cached HTML from inside WordPress. Not quite as fast as server-level caching because PHP still starts up to serve the cache, but a massive improvement over no cache and trivial to set up on any host.

If you install nothing else from this article, install a page cache. For a typical brochure or blog site, this alone can drop TTFB from 800 ms to under 100 ms.

Object caching for the requests you cannot page-cache

Page caching has a blind spot: logged-in users, WooCommerce carts, checkout pages, and anything personalized cannot be served from a static cache, because each visitor needs different output. These requests run the full PHP-and-database cycle every time, which is exactly why an e-commerce site can feel snappy to anonymous visitors and sluggish to logged-in shoppers.

The fix is a persistent object cache backed by Redis (or Memcached). It stores the results of expensive database queries in memory so WordPress does not re-run them on every request. You enable it by dropping in an object-cache.php file, usually via the Redis Object Cache plugin once your host has Redis available. For WooCommerce and membership sites, this is often the difference between a usable admin and an unusable one.

PHP version and OPcache

This is the cheapest big win nobody checks. Sites still running PHP 7.4 are leaving a large amount of raw throughput on the table — PHP 8.2 and 8.3 execute the same WordPress code meaningfully faster and use less memory. Upgrading is usually a single dropdown in your host's control panel. Test on staging first, because a very old plugin can choke on a modern PHP version, but modern WordPress and mainstream plugins are fully compatible.

While you are there, confirm OPcache is enabled. OPcache keeps the compiled bytecode of your PHP files in memory so the interpreter does not re-parse every .php file on every request. Nearly all decent hosts enable it by default, but on cheap shared plans it is sometimes off.

The database: bloat you cannot see

When TTFB is high even with caching in place, the database is usually the culprit. Two specific offenders dominate:

• Autoloaded options. The wp_options table loads every "autoload" row on every single page request. Abandoned plugins routinely leave hundreds of kilobytes of autoloaded junk behind. Anything over roughly 1 MB of autoloaded data is worth investigating.
• Expired transients and orphaned metadata that never get cleaned up, slowly bloating core tables.

Install Query Monitor to see exactly which queries run on a given page, how long each takes, and which plugin fired them. It turns "the site feels slow" into a named, fixable query. For autoload bloat specifically, a tool like the WP-Optimize plugin or a manual look at the largest autoloaded options will show you what to delete.

Trim what runs on every request

Some plugins do work inside the request that the visitor never benefits from. Common drains on TTFB:

• Synchronous external API calls — a social-feed or "live" stats widget that blocks page generation while it waits on a third-party server. Move these to a background process or cache their output.
• The WordPress Heartbeat API firing admin-ajax.php requests too frequently, especially in wp-admin. Most caching plugins let you throttle it.
• Heavyweight page builders and "do-everything" plugins that load on pages where they are not needed.

When the host is the real problem

Sometimes you do everything above and TTFB is still mediocre. At that point, be honest: the hosting tier is the bottleneck. A crowded shared-hosting plan gives your site a thin slice of an overloaded machine, and no plugin can manufacture CPU that is not there. Moving to a VPS (Cloudways), or to managed WordPress hosting with built-in server-level caching and Redis (Kinsta, WP Engine, Rocket.net, SiteGround's higher tiers), is frequently the single change that fixes everything at once. It is not the answer people want to hear, but for a business-critical site it usually pays for itself.

Caching at the edge with a CDN

Even a fast origin still has to be reached, and physics applies: a visitor in Sydney hitting a server in Virginia pays a round-trip penalty on every byte. A CDN that caches the full HTML document at the edge removes the origin from the equation entirely for cache hits, so TTFB becomes the distance to the nearest edge node rather than to your server.

Cloudflare can do this for WordPress, including a feature called Automatic Platform Optimization (APO) that caches HTML at the edge; note that its WordPress plugin has had patchy maintenance, so verify it still fits your setup before relying on it. Regardless of the specific product, the principle holds: caching HTML at the edge is the last layer, and it makes your origin TTFB almost irrelevant for the majority of requests.

The order that actually works

Stack these fixes in order of impact. Enable full-page caching first, add object caching if you run anything logged-in or WooCommerce, upgrade PHP and confirm OPcache, then clean the database and trim runtime work. Re-measure with curl or DevTools after each step so you can see which one moved the needle. If you have done all of it and are still above 600 ms, the conversation is no longer about plugins — it is about your host.