Most WordPress performance guides tell you to enable persistent object caching with Redis or Memcached. The promise: fewer database queries, faster page loads, happier visitors. The reality: if you don’t understand what WordPress caches in memory—and what shouldn’t be cached—you’ll spend hours debugging stale data, broken admin screens, and plugins that stop working.
Persistent object caching is a feature worth using, but only if your site actually needs it and your stack can handle the edge cases. Here’s how it works, when to turn it on, and the one non-obvious setting that prevents most breakage.
What WordPress object caching actually does
By default, WordPress caches objects—database query results, option lookups, taxonomy terms—in PHP memory for the duration of a single page load. Once the request ends, the cache clears. Every new visitor triggers fresh queries.
Persistent object caching extends that lifetime. Instead of storing cached data in PHP’s runtime memory, WordPress writes it to Redis or Memcached, which live outside the PHP process. The cache survives across requests, across visitors, across server restarts (until you flush it or it expires).
For high-traffic sites, this cuts database load dramatically. A single post might generate 50+ queries on an uncached load. With object caching, most of those queries hit Redis instead of MySQL. Page generation drops from 800ms to 200ms.
For low-traffic sites—under 10,000 monthly visits—the difference is negligible. Your database isn’t the bottleneck; network latency and unoptimized images are. Adding Redis adds complexity without measurable speed gains.
When persistent caching breaks things
The most common failure mode: stale data that won’t refresh. You update a post, but the homepage still shows the old title. You change a user role, but the admin menu doesn’t reflect the new permissions. You deactivate a plugin, but its settings page still appears.
This happens because WordPress—and many plugins—assume the object cache clears between requests. They write data once, cache it aggressively, and never invalidate it. When you enable persistent caching, that assumption breaks.
WooCommerce is notorious for this. Product stock counts, cart totals, and session data get cached with long expiration times. If your cache invalidation logic doesn’t account for stock changes, customers see inaccurate inventory. The fix: WooCommerce-specific cache groups marked as non-persistent, or a plugin like Object Cache Pro that handles WooCommerce edge cases automatically.
Membership and LMS plugins—LearnDash, MemberPress, Restrict Content Pro—cache user permissions and course progress. If the cache doesn’t flush when a user upgrades or completes a lesson, access control breaks. You’ll get support tickets claiming “I paid but still can’t access the content.”
The second failure mode: cache key collisions in multisite or multi-environment setups. If your staging and production sites share the same Redis instance without unique key prefixes, updating content on staging can overwrite production cache entries. Your live site serves draft content or test data.
The non-obvious setting: cache group exclusions
Most object cache drop-ins—Redis Object Cache, Memcached Object Cache, Object Cache Pro—let you exclude specific cache groups from persistence. These groups fall back to runtime-only caching, just like default WordPress behavior.
The groups you almost always want to exclude:
- counts — post counts, comment counts, term counts. These change frequently and queries are cheap.
- plugins — plugin metadata. Caching this causes deactivated plugins to linger in memory.
- themes — same reason. Theme switches won’t take effect until you manually flush.
- userlogins and userslugs — user session and authentication data. Caching these across requests creates security risks.
If you’re running WooCommerce, also exclude:
- wc_session_id
- wc_cart_hash
- wc_reserved_stock
For membership plugins, exclude any group containing “user_meta” or “permissions” in the name. Check your plugin’s documentation—most maintain a list of recommended exclusions.
In the Redis Object Cache plugin (the most popular free option), you set exclusions via the WP_REDIS_IGNORED_GROUPS constant in wp-config.php:
define('WP_REDIS_IGNORED_GROUPS', ['counts', 'plugins', 'themes', 'userlogins', 'userslugs']);
Object Cache Pro uses a similar constant: OCP_IGNORED_GROUPS.
When to actually enable persistent caching
Turn it on if:
- Your site gets more than 50,000 pageviews per month, or you run resource-intensive queries (complex WP_Query loops, custom taxonomies with thousands of terms).
- Your hosting plan includes Redis or Memcached as a managed service. Most managed WordPress hosts—Kinsta, WP Engine, Flywheel—provision Redis automatically. If you’re on shared hosting or a basic VPS, setting up Redis yourself adds maintenance overhead.
- You can test on staging first and you have a cache flush strategy. Automatic purging on post updates is table stakes; you also need manual flush access for emergencies.
Skip it if:
- Your site is low-traffic or you’re already using a full-page cache (WP Rocket, LiteSpeed Cache, Cloudflare). Full-page caching delivers bigger performance wins with fewer edge cases.
- You run a membership, e-commerce, or LMS site and you don’t have time to debug cache invalidation issues. The risk of serving stale user-specific data outweighs the speed benefit.
- Your host doesn’t offer Redis, and you’re not comfortable managing it yourself. A misconfigured Redis instance—no password, exposed port, no memory limits—is a security and stability liability.
Want more hosting and performance breakdowns like this? Subscribe to One Two Three Send—we dig into the infrastructure decisions solo operators actually face, no enterprise fluff.
Persistent object caching works when your site’s traffic and query complexity justify it, and when you’ve accounted for the plugins that assume caches don’t persist. If you’re enabling it just because a checklist told you to, you’re adding risk without reward.