Most WordPress Caching Configurations Are Set Up Wrong

Most "configure your caching plugin" guides assume you're running a content blog where pages don't change between visitors. For that use case, caching is straightforward. For any WordPress site with logged-in users, cart functionality, or personalized content, the default settings cause subtle bugs that take hours to diagnose because the bug only appears for the affected visitor, not for you.

Most published walkthroughs on WordPress caching ignore the failure modes that actually break sites. The recommendations are correct for blogs and wrong in specific ways for everything else.

The five failure modes worth knowing

Failure one: cart fragments cached. WooCommerce stores show a cart counter that updates as items are added. The counter is loaded via an AJAX request called "cart fragments." If your caching plugin caches the cart fragment response, the cart counter shows 0 forever for visitors who weren't the first to trigger the cache. Solution: explicitly exclude /?wc-ajax=get_refreshed_fragments from the cache.

Failure two: logged-in user state cached. Sites with membership or user accounts must serve different content to logged-in vs logged-out users. Caching the logged-in version means every visitor sees the cached user's name in the header. Solution: configure the caching plugin to bypass cache when a WordPress login cookie is present.

Failure three: cookie-based personalization cached. Sites that change content based on cookies (geo-detected pricing, A/B test variants, opt-in popup states) need cookies considered in cache key generation. Most caching plugins ignore cookies by default. Result: the first visitor's cookie state gets served to everyone.

Failure four: HTTPS pages cached as HTTP. Sites that recently migrated to HTTPS sometimes have caching plugins still serving cached HTTP responses. Browser shows "mixed content" warnings. Solution: clear all caches after the HTTPS migration; verify the caching plugin respects scheme.

Failure five: dynamic content treated as static. Counters, timers, recently-viewed-items widgets, real-time stock levels all require dynamic generation. Caching the full page caches these too. Solution: use cache fragments (allowing different cache lifetimes for different parts of a page) or AJAX-load the dynamic parts.

What the disagreement looks like

There's some disagreement on whether to enable page-level caching for WooCommerce sites at all. The conservative position is to disable caching entirely and rely on object caching (Redis) plus a CDN for static assets. The aggressive position is to use sophisticated caching plugins (LiteSpeed Cache, WP Rocket) with WooCommerce-specific rules that handle the failure modes above.

Results vary by store size. A WooCommerce store with 50 products and 100 orders/day works fine with the aggressive position. A store with 5,000 products and 1,000 orders/day starts hitting edge cases the rules don't cover, and the conservative position becomes safer.

Common pitfalls

Cache invalidation timing. When you publish a post, the caching plugin should clear the home page cache, the relevant category archives, the tag archives, and the RSS feed. Many caching plugins clear only the post being published, leaving the archives showing stale content.

Object caching without page caching. Object caching (Redis, Memcached) caches database query results in memory. It's an excellent addition but doesn't replace page caching. Many sites enable only one of the two and wonder why performance gains are modest.

Stale browser caches after deploys. A caching plugin that updates the server cache doesn't fix visitors who have the old version in their browser cache. Use versioned asset URLs (most plugins do this automatically with cache-busting query strings) so browsers fetch new versions when you change CSS or JS.

Testing cache from the same browser session. If you're testing cache behavior while logged in as admin, you're not seeing what visitors see. Open an incognito window or use a different browser to test the cached version.

Enabling Gzip compression on a server that already has it. Hosts running LiteSpeed or modern Apache/Nginx already compress responses at the web-server level. Enabling Gzip in the caching plugin on top double-compresses, which is wasteful and occasionally breaks browsers.