Choosing and configuring a WordPress caching plugin

Almost every WordPress performance guide recommends “install a caching plugin,” but caching isn’t one thing. There are several distinct layers involved, a plugin usually only addresses some of them, and configuring it badly can break parts of a site, particularly one running WooCommerce or membership functionality. This post breaks down what caching actually does at each layer, and the settings worth getting right regardless of which plugin you choose.

The different layers of caching

Page caching

This is what most people mean when they say “caching plugin.” Normally, every time a visitor requests a page, WordPress runs PHP, queries the database, and assembles the HTML from scratch. Page caching saves a static copy of the fully rendered HTML the first time a page is generated, then serves that saved copy to subsequent visitors instead of rebuilding the page every time. This is by far the biggest performance win available on most WordPress sites, since it skips the expensive PHP and database work entirely for repeat requests.

Object caching

Object caching works underneath page caching, at the database query level. WordPress runs a large number of database queries on every page load, many of which fetch the same data repeatedly, such as site options or post metadata. An object cache stores the results of these queries in memory, using a system like Redis or Memcached, so that repeated queries for the same data are served from memory instead of hitting the database again. Managed Cloud Hosting plans typically include this as standard, rather than leaving it as something to set up yourself. This matters most for pages that can’t be fully page-cached, such as a logged-in dashboard, a personalised page, or anything involving WooCommerce cart and account pages.

Browser caching

This happens on the visitor’s own device rather than your server. HTTP cache headers tell a visitor’s browser to hold on to static assets, such as images, CSS, and JavaScript files, for a set period rather than re-downloading them on every visit. Most caching plugins can add these headers for you, though they can also be configured directly on the server via .htaccess or your hosting environment’s configuration.

Opcode caching

This one is worth knowing about even though no plugin controls it. PHP OPcache stores the compiled form of your PHP files in memory, so the server doesn’t have to re-parse and recompile the same PHP code on every single request. It’s a server-level setting rather than a WordPress plugin, usually enabled and configured through php.ini or a hosting control panel, and it’s typically already switched on by default on quality WordPress hosting. If you have access to check, confirm OPcache is switched on, since it’s one of the more significant free performance wins available and has nothing to do with which caching plugin you pick.

Page cache and object cache aren’t interchangeable

It’s worth understanding why you might want both rather than treating them as alternatives. Page caching only helps with pages that are the same for every visitor, typically anonymous, logged-out traffic. It does nothing for a logged-in user’s dashboard, a WooCommerce cart, or any page that has to be generated fresh and personalised for each request, because those pages can’t be safely served from a static cached copy in the first place.

Object caching helps regardless of whether a page can be fully cached, because it speeds up the database queries underneath, even on pages that must be dynamically generated. A WooCommerce store with a lot of logged-in, personalised traffic, or a membership site, often benefits more from a well configured object cache than from page caching alone, since so much of the traffic can’t use a page cache in the first place.

Configuration that applies across most plugins

Popular caching plugins differ in their interface, but the underlying settings worth getting right are largely the same regardless of which one you use.

• Exclude logged-in users from page caching, or at least serve them an uncached version. Serving a cached page meant for a different logged-in user is a real privacy risk, not just an inconvenience
• Exclude cart, checkout, and account pages on WooCommerce sites specifically. These pages need to reflect the current visitor’s cart contents and session, and caching them can result in a customer seeing someone else’s cart or a stale total
• Set a sensible cache expiry period and configure automatic cache clearing when content is published or updated, so visitors aren’t served stale content after you make a change
• If you run an object cache, confirm it’s actually connected and being used, most plugins show this status somewhere in their settings screen, since a misconfigured object cache setup can silently fail without any error
• Test the site while logged out, in a private browsing window, after making any caching change, since that’s the perspective most of your visitors actually experience

Caching masks problems, it doesn’t fix them

It’s worth being honest about what caching does and doesn’t solve. If a page is slow because of a genuinely inefficient database query, an unoptimised plugin, or a theme doing unnecessary work, caching hides that problem for as long as the cached copy is being served. The moment the cache expires, or a visitor hits an uncacheable page such as a logged-in dashboard or a WooCommerce cart, the underlying slowness is exactly as bad as it was before.

Caching is a legitimate and often necessary part of running a fast WordPress site, but it works best alongside addressing genuine performance problems, not as a substitute for finding them. If a site still feels slow on uncached pages, or a specific plugin’s admin screens are sluggish even with caching in place, that’s usually a sign the fix needed is somewhere else entirely, such as the underlying hosting resources available to the site.