Speeding Up a Slow WordPress Site: The Order I Actually Work In

"Our WordPress site got extremely slow" is easily one of the most common requests I receive. The immediate instinct for most people is to blindly install a plugin. Usually an image optimizer, or a "speed booster" plugin that loudly promises to fix everything with one click.

Sometimes that genuinely helps a little bit. But the massive, noticeable wins almost always come from things that have absolutely nothing to do with WordPress's plugin ecosystem. Going through them in the wrong order simply means spending hours fighting for a 10% frontend improvement, before even touching the server-side bottleneck causing the other 90% of the delay.

First: Is it the server, or the page?

Before touching a single setting, I strictly check the Time to First Byte (TTFB). This measures exactly how long the server takes to start sending a response, completely separate from how long the browser takes to download and render all the heavy images and scripts after that:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://example.com

A TTFB hovering over half a second on a simple, logged-out page usually means WordPress is desperately doing heavy lifting on every single request. The database is actively being queried, PHP is aggressively executing, and absolutely nothing is cached.

A blazing fast TTFB combined with a brutally slow overall page load heavily points toward frontend issues: oversized images, massive unoptimized scripts, or blocking fonts. That is a completely different (and usually much easier) problem to solve.

If it is the server: Caching, in strict layers

A public WordPress page that looks completely identical to every single visitor (which describes 95% of pages on most sites) absolutely does not need PHP and MySQL to run on every single request.

A robust page cache—whether handled through a solid plugin like WP Super Cache, or much better, completely at the server level with Nginx's fastcgi_cache—serves a static HTML copy and skips PHP entirely. This one single change is very often the dramatic difference between a TTFB of 800ms and a TTFB of 50ms. It is the literal difference between forcing the server to "boot up WordPress" and simply asking it to "serve a text file."

For the requests that actually do need PHP to run—like logged-in users, WooCommerce carts, or anything dynamic—an object cache (like Redis or Memcached) is mandatory. It violently caches the raw results of WordPress's database queries. This means repeated lookups (and WordPress repeats the exact same query dozens of times per page load) instantly hit RAM instead of hammering MySQL:

// wp-config.php, after installing a Redis object cache plugin
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_CACHE', true);

Finally, PHP's native OPcache strictly caches the compiled PHP bytecode itself, so the exact same PHP files do not get painfully recompiled from scratch on every single request. This should simply be permanently enabled in php.ini. It requires absolutely zero WordPress-specific configuration, and it universally speeds up every single PHP request on the entire server.

The database quietly accumulates heavy weight

WordPress's database slowly grows in ways that don't visibly show up until they violently drag the site down. Think post revisions (where every single autosave quietly creates a new database row), expired transients (temporary cached data that often simply never gets cleaned up), and massively orphaned metadata left behind by deleted plugins.

None of this is dramatic on a brand-new, small site. But on a busy site that has been running for three years, it is incredibly common to find a wp_options table where the strictly "autoloaded" options—the ones aggressively loaded into memory on every single page request, regardless of whether they are even needed—add up to several megabytes of pure garbage:

SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC LIMIT 10;

Anything massive in here that came from a plugin that was deleted two years ago is pure, painful overhead added to every single request. Cleaning this up does not require blind guesswork; that SQL query brutally tells you exactly where the dead weight is hiding.

Then, and absolutely only then, the frontend

Once the server finally responds quickly, frontend optimization actually has a solid foundation to build upon. Lazy-loading images, strictly serving modern formats like WebP, and actively deferring non-critical JavaScript finally makes sense.

Doing this frontend work first on a site that has a painfully slow 800ms TTFB is exactly like polishing the visible 20% of a car, while the invisible 80% (the engine) is actively on fire. The time spent before the browser even starts rendering the page goes completely untouched.

Why the exact order matters

Each one of these specific steps is independently useful, but the strict order reflects exactly where the processing time actually goes on a typical slow WordPress site.

Server-side page caching aggressively addresses the biggest chunk of delay for regular logged-out traffic. The object cache and OPcache directly address the brutal compute cost of WordPress itself for everything else. Deep database cleanup permanently removes the accumulated dead weight dragging down every single page. And finally, frontend optimization polishes whatever is left.

Starting from the absolute bottom of that list just because it is the most visible—like compressing an image or minifying a script—feels highly productive. But you are actively optimizing the smallest possible piece of the total load time first.