Performance
WordPress caching explained: which plugin, which settings
7 August 2026 · 7 min read
On this page
Caching is the highest-return performance change you can make from inside WordPress, and the one most often configured badly. Three plugins fighting each other is slower than none.
What caching actually does
Without it, every visit makes WordPress rebuild the page: run PHP, query the database, assemble the HTML. Every time, for every visitor, even though the result is identical.
With page caching, the first visitor triggers that work and the result is saved as a file. Everyone after gets the file. The difference is typically 40–70% on repeat loads.
The layers, and which you need
Page caching. The big one. Saves the finished HTML. You want this.
Browser caching. Tells the visitor's browser to keep your CSS, images and fonts rather than re-downloading them on every page. You want this, and it is usually one toggle.
Object caching. Stores database query results in memory (Redis or Memcached). Significant on busy or dynamic sites, irrelevant on a small brochure site, and it needs host support.
OPcache. Caches compiled PHP at server level. Your host should have this on; you cannot control it.
CDN. Serves static files from a server near the visitor. Worth it if your visitors are geographically spread.
Which plugin
WP Rocket ($59/year). The easiest to get right. Sensible defaults, everything in one place, good support. If you want it configured once and forgotten, this is the answer.
LiteSpeed Cache (free). Excellent if your host runs LiteSpeed — ask them. Server-level caching, much faster than PHP-based alternatives. Useless on Apache or nginx.
W3 Total Cache (free). Powerful, and the most likely to be misconfigured. Enormous number of options, many of which break things.
WP Super Cache (free). Simple, reliable, fewer features. A good safe choice.
Your host's own caching. If your host offers server-level page caching, use it instead of a plugin, not as well. It is faster and conflicts less.
One page caching layer only. A plugin cache plus a host cache plus a CDN cache all holding different versions of your pages is the most common cause of "I updated the page and it still shows the old one".
Settings that matter
Page caching: on. The default reason you installed it.
GZIP or Brotli compression: on. Text files compress by 60–80%. Free performance.
Browser caching / expiry headers: on. Set static assets to expire in a month or more.
Minification: carefully. Combining and minifying CSS and JavaScript helps, and is the setting most likely to break your layout. Turn it on, then check every template. If anything looks wrong, turn off JavaScript minification first — it breaks more often than CSS.
Lazy loading: on, but check your hero image is excluded. Lazy-loading the largest above-the-fold image makes LCP worse, not better.
Preload / cache warming: on if available. Keeps the cache populated so visitors rarely hit an uncached page.
Settings that break things
Caching logged-in users. Never on a site with a members area or shop. Users see each other's pages.
Caching cart, checkout and account pages. WooCommerce sets exclusions automatically — verify they are still there after any cache plugin update. This causes checkout failures that look random.
Aggressive JavaScript deferral. "Delay JavaScript execution" and similar options can improve scores dramatically and break sliders, forms and menus. Test everything.
Removing unused CSS. Big gains, real risk. The tool guesses what is unused and is sometimes wrong, usually on a page nobody checked.
Testing it properly
- Check the page is actually cached. Most plugins add an HTML comment at the bottom of the source. View source and look.
- Test logged out. You are probably excluded from the cache.
- Bypass the cache to measure the server — add
?nocache=1— so you know whether hosting is your real problem. - Check after every settings change: homepage, a form, a logged-in view, and checkout if you have one.
A configuration that works for most sites
Page caching on, GZIP on, browser caching on, lazy loading on with the hero excluded, CSS minified, JavaScript left alone unless you are willing to test carefully, cart and checkout excluded, cache cleared on publish.
That gets most of the available gain with almost none of the risk. The last 10% is where sites break, and it is rarely worth it unless someone is testing thoroughly.
Our speed optimisation includes exactly this, tested across every template, for a fixed $299.