Caching is the single biggest performance lever available on WordPress, and also the source of most "why isn't my change showing up" confusion. That confusion usually comes from treating caching as one thing when it's actually four distinct layers, each solving a different problem.
Layer 1: Page (full-page) caching
The most impactful layer. Instead of running the full WordPress request lifecycle — bootstrapping PHP, querying the database, rendering templates — for every visitor, a full-page cache stores the final rendered HTML and serves that directly for subsequent requests, skipping PHP and the database entirely.
This is why it delivers the biggest speed win: it eliminates the most expensive part of a WordPress request. It's also why it's the layer that causes the classic "I edited the page and nothing changed" complaint — the cache needs to be purged (usually automatic on publish/update, but not always for every trigger) before edits are visible.
Full-page caching must exclude anything visitor-specific — logged-in sessions, cart contents, personalized content — or you risk serving one visitor's private data to another. This is the most common WooCommerce caching bug.
Layer 2: Browser caching
Controlled by HTTP cache headers (Cache-Control, Expires) on static assets — images, CSS, JS. This tells the visitor's own browser to reuse a previously downloaded file instead of re-requesting it, which matters most for repeat visitors browsing multiple pages on your site. Set long cache lifetimes for versioned static assets (files with a hash or version string in the filename, which changes when the file changes) and shorter or no caching for anything that can change without the URL changing.
Layer 3: Object caching
WordPress runs many repeated database queries per page load (options, menus, post meta) that don't need to hit the database every single time within a short window. An object cache (Redis or Memcached) stores the results of these queries in memory, so repeated lookups within a request — or across requests, with a persistent object cache — skip the database round-trip.
This matters most for logged-in traffic, admin-heavy sites, and WooCommerce (cart/session data), where full-page caching can't apply but the underlying data queries are still repetitive. It's the layer that makes a dynamic, can't-be-page-cached page still reasonably fast.
Layer 4: CDN (edge) caching
A CDN caches static assets — and often full HTML pages too — at edge locations geographically distributed near your visitors, rather than serving everything from your single origin server. This primarily attacks network latency: a visitor in Singapore hitting a server in the US pays real round-trip time no amount of server-side optimization fixes. A CDN puts a cached copy physically closer to them.
How the layers interact (and where bugs come from)
A change you make needs to correctly invalidate every layer that might be holding a stale copy — publish a post, and the page cache, any CDN edge cache of that URL, and any object-cached query results referencing it all potentially need purging. Most modern caching setups chain these purges automatically on the relevant WordPress hooks (save_post, transition_post_status), but a custom plugin or an unusual update path (bulk database changes, direct SQL) can bypass those hooks and leave stale cache behind — this is the actual root cause behind most "I don't understand why this is still showing old content" tickets.
Practical setup for most sites
- Page caching: server-level if your host offers it (fastest, skips PHP entirely) — otherwise a well-maintained caching plugin.
- Object caching: Redis, if your host provides it — essential for WooCommerce and any logged-in-heavy site.
- Browser caching: usually handled automatically by your host's or caching plugin's default headers; verify long-lived headers on versioned static assets specifically.
- CDN: worth it for any site with a geographically distributed audience, and effectively mandatory for media-heavy or global sites.
The takeaway
"Turn on caching" isn't one action — it's four separate mechanisms, each solving a different bottleneck (server compute, browser round-trips, database queries, network latency). Understanding which layer is responsible for a given symptom is what turns "the site is fast now" from luck into an actual configuration you understand.
