How to speed up WordPress: 10 steps in order of impact

To speed up WordPress effectively, work in order of impact: turn on page cache so pages are served straight from the web server, move to PHP 8.3 or newer with OPcache, add a Redis object cache for the pages that can't be cached, clean up plugins and the database, and only then tackle images and the front end. Most slow WordPress sites are slow because every view makes PHP build the page from scratch; page cache alone often changes everything.

This guide covers those 10 steps in that order, each with how to measure it, how to do it by hand and the mistakes to avoid. At the end, we show how the server-side steps work in ZoPanel, where most of them are a single switch.

Measure before you speed up WordPress

If you don't measure, you won't know what helped. Track two groups of numbers.

Server side: TTFB (time to first byte). The time from sending a request to receiving the first byte, which is where PHP, the database and caching show up. Measure it with curl from another machine:

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

Run it a few times in a row. An uncached WordPress page on a decent server typically takes a few hundred milliseconds; a cached page often drops to tens of milliseconds plus network latency.

User side: Core Web Vitals. According to web.dev, a page is "good" at LCP ≤ 2.5 s, INP ≤ 200 ms and CLS ≤ 0.1, measured at the 75th percentile of page loads, separately for mobile and desktop. PageSpeed Insights shows both real-user data from Chrome (if the site has enough traffic) and lab data.

Record the numbers for the home page, a post and (if you have one) a product page. Measure again after each step.

1. Turn on page cache: the biggest win

Without page cache, every view runs PHP: load WordPress, load plugins, query the database, build the HTML. With page cache, the web server keeps the finished HTML and hands it to the next visitor, and PHP doesn't run.

How big is the difference? In our own measurements, the same 4 GB Ubuntu VPS hosted about 100 WordPress sites without page cache and 250 with it. For a single site, page cache usually decides the TTFB.

There are two ways to do it:

• Server-level caching (nginx FastCGI cache, or your panel's cache feature): fastest, because requests never reach PHP.
• A caching plugin (writes HTML files that rewrite rules then serve): easy on shared hosting and effective when configured well.

Either way, the cache must bypass logged-in users, carts, checkout, account pages and POST requests, and must purge itself when content changes. Don't stack two page caches (plugin plus server): when something is stale, you won't know which layer is holding it.

2. Upgrade PHP and make sure OPcache is on

WordPress.org's requirements page recommends PHP 8.3 or greater and MariaDB 10.11 or MySQL 8.0 or greater. Newer PHP 8.x releases are generally faster and get security fixes for longer. Test plugins and your theme on a staging copy before switching.

OPcache keeps compiled PHP in memory so PHP doesn't recompile every file on every request. Check it:

php -i | grep -i "opcache.enable"

With PHP-FPM, OPcache is configured per PHP version, so check the version the site actually uses.

3. Redis object cache for pages you can't cache

Page cache can't help wp-admin, WooCommerce carts or membership sites, because those pages are built per user. That's where an object cache comes in: it stores database query results in Redis, so WordPress reads them from RAM instead of asking the database again.

You need two things: Redis running on the server and a plugin such as Redis Object Cache so WordPress uses it. On a server with many sites, give each site its own Redis database or key prefix so no site can read or flush another's data.

4. Find the heavy plugins

One poorly written plugin can add hundreds of queries per page. Install Query Monitor on a staging copy, open a slow page and see which queries and plugins take the most time. For each plugin, ask: do I still need it? Could a few lines of code or a server feature replace it?

A common trap: an "all-in-one speed" plugin with every option ticked, whose JavaScript combining breaks the layout, after which everything is switched off and the conclusion is "optimization doesn't work".

5. Clean the database, especially autoload

Every WordPress request loads all autoloaded options. Uninstalled plugins often leave large ones behind. Check the total:

wp option list --autoload=on --format=total_bytes

The command comes straight from the WP-CLI documentation. If the result runs to several MB, list the largest options and find out which plugin they belong to. Don't delete options you can't identify, and back up the database first. Other cleanups: old revisions and auto-drafts, expired transients, spam comments.

6. Optimize images

Images are usually the heaviest part of a page and often determine LCP.

• Modern formats: WordPress supports WebP since 5.8 and AVIF since 6.5, provided the server's image library (GD or Imagick) supports them. Check under Tools → Site Health → Info → Media Handling.
• The right size: don't serve a 4000 px image in an 800 px slot. WordPress generates several sizes and uses srcset.
• Lazy loading: WordPress adds loading="lazy" to images automatically, but the large image at the top of the page (the LCP image) should not be lazy-loaded.
• Declare dimensions (width, height) to prevent layout shifts and keep CLS down.

7. Replace WP-Cron with server cron

WP-Cron runs on page views, spawns extra PHP requests and can tie up a PHP worker for seconds when the domain resolves slowly. Turn it off and let the server run scheduled tasks. Our guide to replacing WP-Cron with real cron walks through it.

8. Block bots and junk traffic

Scrapers love uncacheable URLs (search, filters, random query strings), and each request is a full page build. Check the access log for the IPs and user agents making the most requests. Per-IP rate limiting at the web server and a web application firewall (WAF) take a lot of load off a site being scraped.

9. Front end: CSS, JavaScript and fonts

Once the server is fast, what's left happens in the browser: render-blocking scripts, fonts from several origins, a heavy theme. Cut the number of plugins that add JavaScript to every page, self-host fonts or use system fonts, and defer scripts that aren't needed up front. Test every change on staging; this is where layouts break most easily.

10. Enough server resources, close to your users

No optimization makes up for a server short of RAM or CPU. Warning signs: 502/503 errors at busy times, PHP workers always maxed out, a server swapping to disk. Put the server near your audience to cut network latency on every request, and use a CDN for static files when visitors are far away.

Speeding up WordPress on ZoPanel

The server-side steps above are built into ZoPanel:

• Page cache: website → PHP & config tab → turn on Page cache. Pages are cached for 10 minutes; logged-in users, carts, checkout, wp-admin, POST requests and URLs with a query string always bypass it (ad-tracking parameters such as utm_*, fbclid and gclid don't count). A small must-use plugin purges the cache when posts, comments, menus, the theme or plugins change. Check it with curl -sI https://example.com/ | grep -i x-cache. The Tuning page lists WordPress sites without the cache and can turn it on for all of them at once. Details in the Websites and PHP documentation.
• PHP version: ZoPanel runs PHP 7.4 through 8.4 side by side, chosen per site on the PHP & config tab.
• Redis object cache: same PHP & config tab; ZoPanel creates a private Redis database for the site and configures the plugin. Redis must be installed on the server under Databases.
• Scheduled tasks: WordPress tab → Maintenance card → Server runs scheduled tasks (every 5 min, not on visits).
• Bots: the Request rate limit card on the PHP & config tab (Light 20/s, Medium 8/s, Strict 2/s) and the web application firewall (ModSecurity + OWASP CRS) on the Tools tab.
• Diagnostics: Logs tab → Run diagnostics tells you whether the site is held back by the package's PHP workers or RAM.

One thing worth knowing: to save memory, the PHP of a site with no visitors for 30 minutes (by default) goes to sleep. The next visit wakes it within a few hundred milliseconds, and compiled code is reloaded from an on-disk OPcache, so the first page is nearly as fast as usual. For premium plans that must avoid even that, turn on PHP always running in the package. See the PHP performance documentation.

Mistakes that keep WordPress slow

• Measuring once, from far away. The first request often hits an empty cache. Measure several times, from near your real users.
• Three caching plugins at once. They step on each other and create bugs that are hard to trace.
• Caching login or cart pages. A customer seeing someone else's cart is far worse than a slow page.
• Optimizing only for the PageSpeed score. Lab scores are useful, but real-user Core Web Vitals are what count.
• Forgetting that WooCommerce isn't a blog. Shops have many uncacheable pages; object cache and enough PHP workers matter more there.

Conclusion

You don't need dozens of plugins to speed up WordPress. Work in order: measure, turn on page cache, upgrade PHP, add an object cache for dynamic pages, clean up plugins and the database, then optimize images and the front end. The first four steps usually deliver most of the gain.

ZoPanel's Free plan includes page cache, Redis object cache, multiple PHP versions and the WordPress Toolkit for 10 websites. Install it with curl -fsSL https://get.zopanel.net | sudo bash on Ubuntu 22.04/24.04 or Debian 12/13, and see the WordPress Toolkit documentation and pricing.

Frequently asked questions

What is the most effective way to speed up WordPress?

Page cache. Cached pages are served by the web server without running PHP or querying the database, so TTFB drops sharply and the server handles far more visitors. In our measurements, page cache raised the number of WordPress sites on the same 4 GB VPS from about 100 to 250.

Which PHP version should WordPress use?

WordPress.org recommends PHP 8.3 or greater. Test your plugins and theme on a staging copy before upgrading, since older plugins may not be compatible.

Do I need Redis if I already have page cache?

For blogs and brochure sites with few logged-in users, usually not. For WooCommerce, membership sites or sites with many people working in wp-admin, a Redis object cache helps a lot, because those pages can't use page cache.

Why is WordPress still slow with a caching plugin?

Usually because the pages aren't actually cached (logged-in users, query strings or cookies that bypass the cache), heavy plugins run on uncacheable pages, or the server runs out of PHP workers. Check the response's cache headers and use Query Monitor to find the bottleneck.

What are good Core Web Vitals values?

According to web.dev: LCP of 2.5 seconds or less, INP of 200 ms or less and CLS of 0.1 or less, measured at the 75th percentile of page loads on mobile and desktop.