WordPress
How to Speed Up a Slow WordPress Site: 11 Fixes That Actually Work
By Adam Eastwood · · 10 min read
Quick answer
Diagnose before you optimise: find whether time is lost in the server response or the front end. Then apply the fixes with the highest yield — page caching, PHP 8.3, an object cache for dynamic sites, modern image formats, a plugin audit, and database cleanup. Most slow WordPress sites need three or four of these, not all eleven.
WordPress is not inherently slow — but the average WordPress site is slower than it should be, because it accumulates themes, plugins and database clutter faster than anyone removes them. The eleven fixes below are ordered so that diagnosis comes first and the highest-yield changes come early. No magic plugins, no invented before-and-after numbers — just the things that reliably work.
One honest framing note: some of these fixes are things you do to your site, and some are properties of wherever it runs — server-side caching, PHP versions and disk speed are hosting decisions as much as site decisions. Our managed CMS hosting handles that layer for WordPress out of the box, but every fix below works on any host that gives you the necessary access.
Where is your site actually slow? (Fix 1: measure first)
The cardinal sin of WordPress performance work is optimising blind. Two free tools tell you almost everything. PageSpeed Insights (or any Lighthouse runner) splits the problem in half: a slow time to first byte means the server is taking too long to build the page — a back-end problem — while good TTFB with bad paint metrics means the page itself is too heavy: a front-end problem. The fixes for each half are different, and knowing which half you are in saves hours.
For the back end, install the Query Monitor plugin and browse your own site. It shows exactly which plugins, queries and remote HTTP calls each page spends its time on — turning “WordPress is slow” into “this one plugin runs a 900ms query on every page”, which is a problem you can actually fix. Remove it from production when you are done.
Which caching and PHP fixes give the biggest wins?
Fix 2: page caching
By default WordPress rebuilds every page with PHP and database queries for every visitor. Page caching stores the finished HTML and serves it directly, and for anonymous traffic to a content site it is the single largest improvement available. Use whichever layer your stack offers — a server-level cache (LiteSpeed, Nginx FastCGI cache, or Varnish) is preferable to a plugin-level one (WP Super Cache, W3 Total Cache, and similar), but either dwarfs having none. Set sensible cache lifetimes and make sure updates purge it.
Fix 3: an object cache for dynamic pages
Page caching cannot help logged-in users, carts, or checkouts — exactly where WooCommerce and membership sites hurt. A persistent object cache (Redis, typically, via a drop-in plugin) stores the results of repeated database lookups in memory, so every dynamic request does less work. If your site is mostly anonymous readers, this is optional; if it is a shop or community, it is the fix that matters most.
Fix 4: run a current PHP with OPcache
Each PHP 8.x release has brought real performance improvements, and WordPress core runs comfortably on PHP 8.3. If you are still on 7.4 or 8.0 — both long past end of life — you are running slower and unpatched. Update plugins and theme first, switch versions on a staging copy, then move production. Confirm OPcache is enabled while you are there; on decent hosting it is, and it spares PHP recompiling WordPress on every request.
How do you slim down a heavy front end?
Fix 5: modern image formats and lazy loading
Images are usually most of a page's weight. Serve WebP or AVIF instead of JPEG and PNG — WordPress has supported WebP uploads since 5.8 and AVIF since 6.5, and optimisation plugins convert existing libraries. Size images to their displayed dimensions rather than uploading camera originals, and let WordPress's built-in lazy loading defer offscreen images. One exception: make sure the main above-the-fold image is not lazy-loaded, or you worsen your largest paint instead of improving it.
Fix 6: audit plugins by cost, not count
With Query Monitor data in hand, review the list. Deactivate and delete what you no longer use; replace anything that loads scripts and styles on every page while being used on one; be especially wary of plugins that make remote HTTP calls during page loads. “Related posts”, social feeds, and broken-link checkers are recurring offenders. This is an evidence exercise, not a purge by instinct.
Fix 7: weigh your theme and builder honestly
Multipurpose themes and page builders trade performance for flexibility, shipping large CSS and JavaScript bundles to every visitor. You do not have to rebuild the site today — but when a redesign comes, a lean theme or block-based design will remove a layer of weight no cache can hide. In the meantime, disable builder modules and theme features you do not use.
Fix 8: cut third-party scripts
Analytics, tag managers, chat widgets, embedded fonts, ad pixels — each is a request to someone else's server on your critical path. Inventory them, delete the abandoned ones, and self-host your fonts (or use system fonts). This is often the cheapest front-end win on business sites, because half the scripts serve nobody.
What about the database and the hosting?
Fix 9: clean up the database
Years of use leave sediment: hundreds of revisions per post, expired transients, and — the quiet killer — autoloaded options, which WordPress loads on every single request. Plugins routinely leave autoloaded rows behind after uninstall, and multi-megabyte autoload totals measurably slow every page. Cap revisions in wp-config.php, clear expired transients, and review the largest autoloaded rows (a cleanup plugin like WP-Optimize, or WP-CLI, will list them). Back up first.
Fix 10: fix the slow queries you found
Where Query Monitor showed genuinely slow queries, deal with the source rather than caching over it: update or replace the plugin responsible, and for large sites consider indexes on commonly queried meta fields. WooCommerce sites with tens of thousands of orders and layered-navigation filtering are the classic case — sometimes the answer is a search plugin that moves filtering out of MySQL entirely.
Fix 11: move hosting last, not first
Better hosting is a real fix — faster CPUs, NVMe storage, server-level caching and more PHP workers lift everything at once — but it is deliberately last on this list. Moving an unoptimised site to faster hosting buys a one-off improvement and carries every problem with it. Apply fixes 1–10 first; then, if TTFB is still poor on a tuned site, the host is genuinely the bottleneck and a move will actually pay off.
Which fixes should you do first?
| Fix | Typical impact | Effort | Applies to |
|---|---|---|---|
| Measure (Query Monitor, PSI) | Enables the rest | Low | Everyone |
| Page caching | Very high | Low | Anonymous traffic |
| PHP 8.3 + OPcache | High | Low–medium | Everyone |
| Object cache (Redis) | High | Medium | Shops, logged-in users |
| Image formats + lazy loading | High | Low | Image-heavy sites |
| Plugin audit | Varies — often high | Medium | Everyone |
| Third-party script cut | Medium | Low | Business sites |
| Database cleanup | Medium | Low | Older sites |
| Theme/builder diet | Medium–high | High | Builder-based sites |
| Slow-query fixes | High where present | Medium–high | Large sites |
| Better hosting | High | Medium | After the rest |
Frequently asked questions
What is the single biggest cause of a slow WordPress site?
There is no universal answer, which is why measuring first matters — but the most common pattern is uncached PHP rendering on every visit, compounded by a heavy theme and too many plugins. Page caching alone transforms that case, which is why it is the first fix to apply after diagnosis.
Do I need both page caching and object caching?
They solve different problems. Page caching serves stored HTML to anonymous visitors and is the bigger win for content sites. Object caching (Redis or Memcached) speeds up the dynamic requests page caching cannot help — logged-in users, WooCommerce carts and checkouts, and admin screens. Busy dynamic sites benefit from both.
Will upgrading PHP break my WordPress site?
Usually not if your plugins and theme are actively maintained, but test rather than hope: PHP 8.x removed behaviour that very old plugins relied on. Update everything, then switch PHP on a staging copy first. Sites still running PHP 7.4 — long past end of life — are leaving both speed and security patches on the table.
Do plugins slow WordPress down?
The count matters less than the composition. Thirty small single-purpose plugins can be harmless while one poorly written one drags every page down with slow queries or remote calls on every load. Measure with Query Monitor before uninstalling things on instinct — the heaviest plugin is often not the one you would guess.
The bottom line
Speeding up WordPress is not one heroic fix; it is measurement followed by the three or four changes your measurements point at. For most slow sites that means page caching, a current PHP, honest image handling, and removing the one plugin doing something silly on every request — with Redis added when logged-in traffic matters and a hosting move reserved for when a tuned site is still slow. Do the diagnosis, work the list in order, and re-measure after each change so you know which fixes earned their keep.