# WordPress Caching Explained

- Link: https://offshorehosting.pk/wordpress-caching-explained/
- Published: 2026-10-25T10:13:00+00:00
- Author: admin

# 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:

    ```php
    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:

  |  Action |  What it clears |  Where |  
   |  Clear cache |  Stored page cache files |  Caching plugin or host panel |  
 |  Flush cache |  The object cache store |  WP-CLI (`wp cache flush`), Redis, Memcached |  
 |  Purge cache |  Cached copies at the server or CDN edge |  Caching plugin, host panel, CDN dashboard |  
 |  Hard refresh |  The browser’s stored copy |  Visitor’s browser (Ctrl/Cmd + Shift + R) |

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](https://offshorehosting.pk/blog/how-to-choose-wordpress-hosting-2026/)
and [How to Migrate a WordPress Website Safely](https://offshorehosting.pk/blog/how-to-migrate-a-wordpress-website-safely/).
See our [WordPress hosting plans](https://offshorehosting.pk/wordpress-hosting/).

---

_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/