WordPress Caching Explained

Without caching, every visit to a WordPress page is a construction project: PHP runs, dozens of database queries execute, the theme renders HTML, and the result is sent to the visitor. With caching, most visitors get a pre-built copy instead — and the difference in speed is often dramatic. Caching is also the most common cause of confusion on a WordPress site: “I changed the page, but it still shows the old version” is almost always a cache doing its job.

What caching actually does

Caching stores the result of expensive work so it does not have to be repeated. A WordPress page load involves several expensive steps: compiling PHP, querying the database, and rendering HTML. Each cache layer stores the result of one of those steps, so the next visitor skips it.

The key idea is that a cached copy is a snapshot in time. It is fast precisely because it is not freshly generated — and it stays correct only as long as nothing has changed since the snapshot was taken. Good caching is therefore about two things: caching the right things, and invalidating (clearing) the cache when the underlying content changes.

The layers, from visitor to server

A single page view can pass through five or six caches. Here they are in the order a request meets them.

1. Browser cache

The visitor’s browser stores static assets — images, CSS, and JavaScript — on their own device, for as long as the Cache-Control header sent with each file allows. On a repeat visit, the browser reuses those files instead of downloading them again. You control this through your server or caching plugin, by setting cache headers on static files; a common setup caches assets for weeks or months and uses versioned filenames (for example, style.css?ver=1.2) so an updated file gets a new URL and is fetched fresh. Browser cache is also why “clear your cache” is the standard first fix for a stale page — a hard refresh (Ctrl/Cmd + Shift + R) usually solves it.

2. CDN cache

A content delivery network (CDN) stores copies of your site’s static assets — and sometimes full pages — on edge servers around the world, so visitors download them from a nearby server instead of your origin server. This reduces both load time and the load on your server.

CDN caching is configured in the CDN’s dashboard, not in WordPress. The important settings are which file types to cache, how long to cache them, and how to purge the cache when content changes. Most CDNs let you purge a single URL or the entire cache; after publishing a major change, a purge is often needed before visitors see it.

3. Page cache

Page caching stores the entire HTML output of a page, so subsequent requests are served without running PHP or touching the database. For most WordPress sites, this is the single biggest performance win. It can be implemented with a caching plugin (such as WP Super Cache, W3 Total Cache, or LiteSpeed Cache) or at the server level (such as Nginx FastCGI cache or Varnish), which is faster still because the request never reaches PHP.

Two rules govern page caching. Never cache pages for logged-in users — they see personalised content, and serving them a cached page built for someone else is a privacy and correctness problem. Good setups exclude logged-in users, the cart, checkout, and account pages automatically. And cache invalidation must be automatic: when you publish or update a post, the cache for that post (and usually the homepage and archives) should be cleared automatically.

4. Object cache

Object caching stores the results of expensive operations — most often database queries, computed values, and API responses — in RAM, using a key-value store such as Redis or Memcached, so repeat requests skip the database entirely.

WordPress ships with a built-in object cache, but it lasts only for a single page load: it is rebuilt on every request. A persistent backend makes it survive across requests. You enable it by installing a plugin (such as Redis Object Cache) that provides a object-cache.php drop-in file, and defining the connection in wp-config.php — for example:

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );

Persistent object caching matters most where page caching cannot help: WooCommerce stores, membership sites, and any site where visitors are logged in. On a mostly static blog, page caching alone is usually enough.

5. Opcode cache (OPcache)

Before PHP code can run, it must be compiled into bytecode. OPcache stores that compiled bytecode in shared memory, so PHP skips the compilation step on every request after the first.

OPcache is a PHP extension, not a WordPress plugin. It should be enabled on the server by default; on most modern hosts it is. If you manage your own server, enable it with opcache.enable=1 in the PHP configuration and give it enough memory (256 MB is a common setting for WordPress). After deploying code changes, OPcache may need a restart of PHP-FPM or a cache reset before the new code takes effect — this is a common cause of “I updated the plugin but nothing changed” on self-managed servers.

6. Transients

WordPress’s Transients API stores temporary data in the database — for example, the result of an external API call that is expensive to repeat. When a persistent object cache is enabled, transients are usually served from the object cache instead, which is faster. You rarely configure transients directly, but you may need to clear them with wp transient delete --all via WP-CLI (use with care on a live site, as it forces every transient to regenerate on the next request).

How the layers work together

For a typical anonymous visitor to a cached page, the browser checks its own cache for static assets, the CDN serves cached assets and possibly the cached page, and the server’s page cache serves the stored HTML without running PHP. Only on a cache miss does PHP run — and then OPcache skips recompilation, the object cache skips repeated database queries, and the result is stored in the page cache for the next visitor. Each layer removes work from the one below it, which is why a well-configured site can serve thousands of requests with very little server load.

Setting up caching without breaking your site

A safe order of operations:

1. Start with page caching. Install one caching plugin (not two — multiple caching plugins conflict) or use your host’s built-in server caching. Test the site thoroughly: homepage, posts, forms, and — if it is a store — the cart and checkout.
2. Check the exclusions. Confirm that logged-in users, cart, checkout, and account pages are excluded from the page cache. Test while logged in.
3. Add browser caching headers for static assets, with versioned filenames so updates propagate.
4. Add a persistent object cache (Redis) only if you need it — for a store, a membership site, or a site where the admin area feels slow. Verify the hit rate in the plugin’s dashboard; a hit rate below 80% suggests misconfiguration.
5. Add a CDN for static assets if your audience is geographically spread out.

When your change is not showing: clearing the right cache

“If you changed something and it is not showing, you need to clear, flush, or purge whichever cache layer is holding the old version.” The words mean slightly different things:

Work through the layers in order: hard-refresh your browser first, then clear the page cache, then purge the CDN cache, then flush the object cache. In most cases the problem is the page cache or the CDN cache; object and opcode caches matter more for developers pushing code updates.

Caching mistakes to avoid

• Two caching plugins at once. They conflict, double-cache, and produce stale or broken pages. Pick one.
• Caching pages for logged-in users. A privacy problem and a correctness problem. Exclude them.
• Caching the cart and checkout. A cached checkout page can show one customer’s details to another. Exclude all e-commerce pages.
• Aggressive JavaScript optimisation without testing. Minification and delayed loading can break scripts that expect to run immediately — especially payment gateways. Test every optimisation on staging first.
• Forgetting the CDN after a redesign. A full-site purge is needed after a theme change, or visitors will see a mix of old and new assets.

The bottom line

Caching is not one thing — it is a stack of layers, each storing the result of a different expensive step. Page caching is the biggest win for most sites; browser and CDN caching handle static assets; a persistent object cache helps dynamic and logged-in experiences; OPcache speeds up PHP itself. Set them up one at a time, exclude logged-in and e-commerce pages, and learn the difference between clearing, flushing, and purging — because the day your change does not show up, knowing which layer holds the old copy is the whole fix.

Related reading: How to Choose WordPress Hosting in 2026 and How to Migrate a WordPress Website Safely. See our WordPress hosting plans.

---

Reviewed 25 October 2026. Prices, plan contents, and availability for Offshore Hosting plans are [TO BE CONFIRMED] — this article does not state them.

Sources

• WordPress.org — WP_Object_Cache class reference: https://developer.wordpress.org/reference/classes/wp_object_cache/
• DreamPress Glossary — What Is a Cache? Web Caching Explained: https://glossary.dream.press/glossary/hosting/cache/
• InstaWP — How to Clear Cache in WordPress: 9 Methods (2026): https://instawp.com/clear-cache-in-wordpress/
• Savvy — What is Cache in WordPress? Types and Benefits Explained: https://savvy.co.il/en/blog/wordpress-speed/what-is-cache-and-cache-types/

← All guides · Knowledge Base