Web Hosting Cache Explained: The 4 Layers and What Each One Does

The Six-Layer Cache Model Every WordPress Site Has (Whether You Know It or Not)

Every WordPress hosting setup already has all six cache layers — but most of them are running in their worst possible state. Your browser has a cache. Your CDN has a cache. Your server has a page cache, an object cache, an OPcache, and a database cache. Install WordPress fresh with no plugins and all six exist in some form. The question is not whether caching is happening. The question is whether it is configured to help you.

Here is what each layer does and what happens when it is not configured:

The practical takeaway: page cache is the highest-impact layer to configure because it eliminates the two most expensive operations (PHP and database) for the most common case (public, non-personalized pages). Object cache is the highest-impact layer for sites where full page caching is not possible, like WooCommerce with active shoppers. OPcache should be verified enabled, not configured from scratch. The browser cache and database buffer pool are largely set-and-forget once you handle them once.

Cache Request Lifecycle: What Happens the Moment a Request Arrives

Every cache layer makes the same decision in microseconds: do I have a valid copy of this response, or do I need to generate it? Understanding this decision tree is what makes cache debugging tractable. When something is slow or broken, you can trace exactly which layer is failing and why.

The Bypass Conditions That Break Hit Ratios

Cache plugins and CDNs automatically bypass cache under specific conditions. Knowing these conditions tells you exactly where your hit ratio is leaking.

• Authenticated sessions: Any request with a wordpress_logged_in_* cookie bypasses page cache. Editors, admins, and logged-in members never get cached HTML pages.
• WooCommerce cart cookies: Once a visitor adds to cart, the woocommerce_cart_hash cookie is set. Most cache configurations treat this as a bypass signal for all pages, not just cart/checkout.
• Cache-Control: no-store: If your origin (a plugin, security tool, or server config) sends this header, every cache layer in the chain obeys it and stores nothing.
• URL query strings: Some cache configurations treat ?preview=true or ?s=searchterm as uncacheable dynamic URLs, sending them to backend on every request.
• POST requests: Page cache only covers GET requests. Form submissions, AJAX calls, and REST API requests go straight to backend.

Page Cache vs Object Cache: The Distinction That Determines Your Strategy

Ask ten WordPress developers what caching is and nine will describe page cache. The tenth will say "depends on the page." That tenth person has a WooCommerce store, and they understand why object cache exists. The distinction between these two types determines every implementation decision you make — which plugin to use, whether to pay for Redis, and what to do when full-page caching is not possible.

The Combination That Actually Wins

The confusion comes from treating these as an either/or choice. They are complementary. A complete WordPress cache strategy uses both: page cache handles logged-out visitors (the majority of traffic for most sites), object cache handles logged-in users and dynamic pages. The page cache absorbs 80-95% of your traffic load. The object cache makes the remaining 5-20% (authenticated users, cart sessions, WooCommerce queries) significantly faster.

Here is how the combination works in practice for a WooCommerce store. A first-time visitor lands on a product page. Page cache serves the pre-rendered HTML in 30ms. That visitor adds to cart. Now WooCommerce sets a session cookie. Every subsequent page load for that visitor bypasses page cache. Object cache steps in: when WordPress looks up product availability, user metadata, or navigation menus, these values are pulled from Redis in microseconds instead of queried from MySQL. The page is still generated by PHP, but it is generated much faster because the expensive operations are cached at the object level.

Best WordPress Cache Plugins in 2026: Honest Comparison

There are six plugins worth considering. Four of them are the right choice for four very different situations. Install the wrong one and you either pay for features your server cannot use, or you leave your best performance layer unconfigured. I have worked with all six across dozens of WordPress setups. The choice is not about which is "best" — it is about which fits your server and your site type.

WP Rocket: The Paid Plugin Most Sites Should Choose

WP Rocket is not the cheapest option, but it is the one that works correctly with no configuration for most WordPress setups. The defaults are sane. The WooCommerce exclusions are pre-configured. The CDN integration with Cloudflare purges cache automatically on publish. I recommend WP Rocket for any WordPress site on an Apache or Nginx host that does not run LiteSpeed. At $59/year for a single site, it costs less than an hour of developer time spent debugging a misconfigured free plugin. One caveat: WP Rocket does not manage object cache. Pair it with the Redis Object Cache plugin separately if your host supports Redis.

LiteSpeed Cache: The Fastest Free Option (With a Critical Requirement)

LiteSpeed Cache is the single most powerful free cache plugin available, but it requires LiteSpeed web server to unlock the features that make it special. On a LiteSpeed host, it manages page cache at the server level (not PHP level), object cache via Redis, image optimization, critical CSS generation, and CDN configuration from a single plugin. On an Apache or Nginx host, most of these features are disabled. Before installing LiteSpeed Cache, check your server type in cPanel or by running curl -sI yourdomain.com | grep -i server. If the Server header shows LiteSpeed, install LiteSpeed Cache. If it shows Apache or Nginx, install WP Rocket or FlyingPress instead.

FlyingPress: The Best Performance-Per-Dollar Paid Option

FlyingPress launched in 2020 and has quietly become the most technically sophisticated paid cache plugin. Its critical CSS generation is faster than WP Rocket's. Its Redis object cache integration is built in and requires no separate plugin. Its page caching logic handles edge cases like WooCommerce exclusions more granularly than most competitors. At $99/year for a single site, it is more expensive than WP Rocket's single-site price. The price is worth it for performance-focused developers managing complex WordPress setups on non-LiteSpeed hosts who want everything in one plugin.

W3 Total Cache: Maximum Flexibility, Maximum Complexity

W3 Total Cache can do more than any other free plugin. Page cache, database cache, object cache, browser cache, minification, CDN integration, varnish integration, fragment cache — it handles every layer. The problem is that it requires you to configure each layer correctly. The default settings are often wrong. A W3 Total Cache install I audited last year had page cache enabled but the cache directory pointed to a RAM-limited tmpfs mount, CDN URLs configured but the CDN pull zone was not created, and minification enabled on a site that used a page builder that generated inline CSS, breaking the layout. The plugin has free tier and a Pro version at $99/year for commercial features like New Relic integration and fragment caching. Use it only if you are comfortable reading documentation and testing each setting.

Cloudflare APO: Not a Plugin, an Architecture Decision

Cloudflare APO is not a traditional cache plugin. It is a Cloudflare Worker that caches full WordPress HTML pages at Cloudflare's edge globally. The WordPress plugin that enables it handles cache purge signaling only. This matters because APO solves a problem no on-server cache plugin can: geographic latency. A cached page served from a Cloudflare edge node in Mumbai to an Indian visitor arrives in 15ms. The same page served from a cached file on your Texas server takes 250ms for physics alone. APO costs $5/month on the Cloudflare free plan or is included in Cloudflare Pro. For any site with significant international traffic, APO is the highest-impact cache investment per dollar available.

Object Cache Deep Dive: Redis vs Memcached for WordPress

The object cache conversation always collapses to "Redis or Memcached?" The honest answer: Redis. Not because Memcached is bad, but because Redis has one property that makes it categorically more reliable for WordPress specifically: persistence. Memcached loses everything in RAM when the server restarts. Redis does not. For a WooCommerce store, losing the object cache on every server restart means a cold-start database hammering on your busiest traffic periods. After a restart during a traffic spike, you are back to querying MySQL for every transient, every menu, every product availability check. Redis warms back up from its persistent store. Memcached starts from scratch.

Setting Up Redis on WordPress

Redis availability varies by host. ScalaHosting and Cloudways both include Redis on their plans. Kinsta, WP Engine, and Pagely manage Redis automatically as part of their WordPress environment. On a VPS where you have root access, Redis installs in minutes:

# Install Redis
sudo apt install redis-server -y

# Verify Redis is running
redis-cli ping
# Expected: PONG

# Check Redis version
redis-cli --version

# In WordPress, install the Redis Object Cache plugin:
wp plugin install redis-cache --activate

# Enable the object cache dropin:
wp redis enable

# Verify connection:
wp redis status

After enabling Redis, verify it is actually serving cache hits rather than sitting idle. The Redis Object Cache plugin's dashboard shows hit/miss ratios in real time. A healthy WordPress install with Redis should see 60-90% hit ratios on object cache within minutes of enabling it on a site with real traffic.

Object Cache Pro vs the Free Redis Plugin

The free Redis Object Cache plugin (by Tillman Bauknecht) is the standard WordPress Redis integration and works correctly for most sites. Object Cache Pro is a paid alternative ($95-$450/year depending on tier) built specifically for high-traffic WordPress and WooCommerce sites. The meaningful technical differences: Object Cache Pro uses a persistent connection per PHP worker (rather than reconnecting per request), supports Redis Cluster for high-availability setups, and has more granular per-group TTL controls. For sites under a few hundred concurrent users, the free plugin is sufficient. For WooCommerce stores handling hundreds of concurrent active shoppers, Object Cache Pro's connection handling is measurably better under load.

When Object Cache Does Not Help

Object cache is useless if page cache is serving the request. A cached HTML page bypasses PHP entirely. There is no object cache lookup because PHP never runs. Object cache is also not helpful for queries that are inherently uncacheable — queries that return different results based on user session data, real-time inventory, or time-sensitive pricing. Cache what is cacheable, and accept that some data must always go to the database. The goal is not to cache everything. It is to identify the expensive operations that run repeatedly and cache those specifically.

PHP OPcache Internals: The Cache Layer Most People Never Think About

OPcache is the only cache layer in this guide that you almost certainly did not configure and are already benefiting from — because most quality hosts enable it by default. But "enabled" and "configured correctly" are different things, and the difference is visible in TTFB.

What OPcache Actually Does

PHP is an interpreted language. Without OPcache, every PHP file your WordPress install touches during a request goes through four steps: read from disk, tokenize (lex), parse into an abstract syntax tree, compile to opcodes, execute. A WordPress page load touches 100-200 PHP files. Without OPcache, these first four steps happen for every file on every request. With OPcache, the compiled bytecode is stored in shared memory after the first compilation. Subsequent requests skip steps one through four and execute the already-compiled bytecode directly from RAM.

The practical impact on a WordPress site with 20 active plugins: PHP compilation time per request drops from 40-120ms to near zero. This improvement compounds with page cache (which eliminates PHP entirely for cached pages) and object cache (which reduces database round trips). OPcache is not a substitute for page cache — it is a multiplier on every request that PHP does execute.

The Configuration Settings That Actually Matter

; Enable OPcache
opcache.enable=1

; Memory allocated for compiled code (in MB)
; 128-256 MB is appropriate for most WordPress installs with many plugins
opcache.memory_consumption=256

; Max number of files that can be cached
; Default 10000 is too low for complex setups; set to 20000+
opcache.max_accelerated_files=20000

; Check for file changes every N seconds (0 = never check, requires manual reset)
; Set to 0 on production, 1-2 on staging
opcache.validate_timestamps=0

; Reuse memory after cache fills up
opcache.revalidate_freq=0

; String interning memory (set to 16 MB)
opcache.interned_strings_buffer=16

; Recommended: enable for production
opcache.fast_shutdown=1

The most impactful single setting is opcache.validate_timestamps=0. When set to 1 (the default), PHP checks each cached file's timestamp on every request to see if the file changed. On a server with hundreds of PHP files, these stat() syscalls add up. Setting this to 0 tells OPcache to trust its compiled cache indefinitely. The tradeoff: you must manually reset OPcache after deploying code changes. For most WordPress sites that update via the admin dashboard, this reset happens automatically via the plugin API.

How to Verify OPcache Is Working

# Basic OPcache status
wp eval 'print_r(opcache_get_status(false));'

# Look for these key values in the output:
# opcache_enabled => 1 (it is on)
# memory_usage.used_memory => should be well below memory_consumption setting
# opcache_statistics.hits => increasing on repeated calls
# opcache_statistics.misses => should decrease as cache fills

# Alternative: use PHP's built-in function directly
wp eval 'var_dump(function_exists("opcache_get_status"));'
# Returns bool(true) if OPcache is available

After verifying OPcache is enabled and configured, one more thing to check: whether opcache.memory_consumption is set high enough that the cache is not full. A full OPcache evicts older entries and recompiles them, which creates random performance degradation that looks like an intermittent slow server. If memory_usage.used_memory is above 85% of memory_consumption, increase the allocation.

Cache Invalidation: The Hardest Part of Caching That Nobody Explains Properly

Phil Karlton famously said there are only two hard things in computer science: cache invalidation and naming things. He said this because cache invalidation has a fundamental tension: the longer you cache something, the faster your site is — and the longer visitors might see outdated content after you change it. Every caching decision is a choice about where on this spectrum to land.

Stale Cache: When Fast Content is Wrong Content

Stale cache is a cached response that no longer reflects the current state of your content. You update a product price. The old price is cached. Visitors see the wrong price for the next 30 minutes until TTL expires. You fix a typo in a blog post. The corrected version does not appear until the cache clears. For a personal blog, stale cache for 30 minutes is acceptable. For a WooCommerce store running a flash sale, stale cache for 30 minutes can mean customers see the wrong price, add to cart, and reach checkout to find the price changed. That is a conversion killer.

The solution is not to turn off caching. It is to configure targeted invalidation: clear only the specific URLs affected by a content change, immediately after the change. This is what WP Rocket's cache purge-on-update does. This is what LiteSpeed Cache's event-triggered purge does. A "clear entire cache" approach on every post save is lazy invalidation — it solves the stale content problem by destroying your entire cache hit ratio after every small update.

The Correct Invalidation Strategy by Site Type

Cache Warming: Making Purge Painless

The problem with smart invalidation is the first request after purge. That request triggers full PHP and database execution on a cold cache, delivering your worst possible response time to the first visitor after each update. On a small site with 20 pages, this is barely noticeable. On a site with 5,000 pages where you clear the entire cache on a plugin update, you have 5,000 cold pages waiting to hammer your server simultaneously as the next morning's traffic arrives.

Cache warming solves this by crawling your pages programmatically after a purge, before real traffic arrives. WP Rocket's preloader crawls your sitemap immediately after any cache clear. FlyingPress warms on schedule and on-demand. LiteSpeed Cache can be configured to crawl after purge events. The correct setup: purge targeted URLs, immediately re-warm them by requesting them with a crawler, so the next real visitor always gets a cache HIT.

WooCommerce Dynamic Exclusions in Practice

The standard WooCommerce cache exclusion list that every major plugin pre-configures:

URLs to exclude from page cache:
/cart/
/checkout/
/my-account/
/order-received/
/add-to-cart/
/wc-api/
/?wc-ajax=*

Cookies that trigger cache bypass:
woocommerce_cart_hash
woocommerce_items_in_cart
woocommerce_recently_viewed
wp_woocommerce_session_*
wordpress_logged_in_*

Note: /shop/ and /product/* can be cached for logged-out visitors
without the above cookies. These are the high-traffic pages that
benefit most from page cache.

The decision on product pages requires nuance. Product pages can be cached for unauthenticated visitors without cart cookies. But if your product pages show dynamic elements like "X people viewing this," real-time stock counts, or personalized recommendations, those specific elements must be loaded via JavaScript after the cached page loads rather than embedded in the cached HTML.

Common Cache Problems and Exactly How to Fix Them

Every cache problem I have encountered in practice falls into one of two categories: cache is serving content it should not (wrong content to wrong user), or cache is not serving content it should (constant MISS, defeated cache). Both are diagnosable in under five minutes with the right approach. This section is the troubleshooting reference.

Diagnosing Any Cache Problem With curl

Before touching any plugin settings, run this first. It tells you exactly what your server is returning and whether any cache layer is active.

# Step 1: Check cache status headers for any URL
curl -sI https://yourdomain.com/any-page/

# Key headers to look for:
# CF-Cache-Status: HIT / MISS / BYPASS / DYNAMIC (Cloudflare)
# X-Cache: HIT / MISS (Nginx, Varnish)
# X-LiteSpeed-Cache: hit / miss (LiteSpeed)
# X-WP-Rocket: served (WP Rocket)
# Age: [seconds] — how long this response has been in cache

# Step 2: Check what Cache-Control your server sends
curl -sI https://yourdomain.com/ | grep -i "cache-control\|x-cache\|cf-cache"

# Step 3: Check whether cookies are causing bypass
# Test the same URL with and without WooCommerce cookies
curl -sI https://yourdomain.com/shop/ \
  --cookie "woocommerce_cart_hash=ANYTHING" | grep -i cache

# If status changes to BYPASS with cookie present — WooCommerce bypass is working correctly
# If status is BYPASS without cookie — something else is causing bypass (check Cache-Control header)

# Step 4: Verify page source for cache markers (WP Rocket specific)
curl -s https://yourdomain.com/ | tail -20
# Look for 

Logged-In Users Seeing Cached Content

This is the most dangerous cache failure mode. A logged-in admin edits a draft, and a public visitor sees the draft because the cache did not differentiate between the authenticated request and the public one. This should not be possible with any properly configured cache plugin, but it happens when someone disables the "exclude logged-in users" setting or sets up a custom cache rule that overwrites the default bypass logic.

Fix: Verify your cache plugin's bypass settings include wordpress_logged_in_* in the cookie bypass list. Test by logging in, viewing a page, logging out in a different browser, and confirming the logged-out version looks correct. Never test cache behavior while logged in to WordPress admin — you are always getting the bypassed, uncached version.

The Admin Bar on Cached Pages Problem

This happens when a page is cached while an administrator was logged in and the admin bar was visible. The cached HTML includes the admin bar markup, and public visitors see the WordPress admin bar on the live site. This is a configuration error: the cache was not excluding logged-in users when the capture happened, or a plugin forced a cache rebuild while an admin was active.

Fix: Clear all page cache. Verify logged-in user exclusion is active. Rebuild cache by visiting pages while logged out. If using WP-CLI: wp cache flush followed by wp rocket clean (if using WP Rocket).

Plugin Conflicts: The Stale dropin Problem

When you switch from one cache plugin to another, the old plugin's object-cache.php and advanced-cache.php dropins in wp-content/ may remain. The new plugin tries to install its own dropins. Two plugins' dropins coexist. The result ranges from a site that silently serves incorrect cache to PHP fatal errors on every request.

# Check for dropin files
ls -la wp-content/advanced-cache.php
ls -la wp-content/object-cache.php

# If dropins exist from an old plugin you've deactivated:
# Delete them (after verifying your new plugin is active and will recreate them)
rm wp-content/advanced-cache.php
rm wp-content/object-cache.php

# Then let your active plugin recreate them:
# WP Rocket: deactivate and reactivate the plugin
# Redis Object Cache: wp redis disable && wp redis enable
# LiteSpeed Cache: go to LiteSpeed Cache > Manage > Enable Object Cache

Where to Go Next

Caching is the performance layer that sits in the middle of your entire infrastructure stack. To the left of caching is your hosting environment: the server quality, PHP-FPM pool size, MySQL buffer pool, and network latency that determines how fast your cache misses resolve. To the right is your asset delivery: whether images are optimized, whether JavaScript is deferred, whether the CDN is delivering static files from edge nodes close to your visitors.

The TTFB guide breaks down every millisecond of server response time and explains exactly which optimization fixes each phase. If your page cache is working correctly but TTFB is still above 300ms, the TTFB guide will identify which non-cache layer is the bottleneck. The CDN explainer covers how page cache and CDN cache interact, why Cloudflare APO caches WordPress pages at the edge rather than just assets, and when CDN hit ratios drop because of WooCommerce sessions. For the underlying server infrastructure that determines how fast cache misses resolve, the web hosting infrastructure guide explains CPU, RAM, disk I/O, and database configuration in detail. If you are running WooCommerce specifically, understanding database optimization alongside object cache is the next logical layer to address once caching is configured correctly.