Most WordPress performance guides tell you to enable object caching. Few explain what it actually caches—or when clearing it causes more problems than it solves.
Object caching sits between WordPress and your database. When a plugin or theme requests data—post metadata, user details, term relationships—WordPress checks the cache first. If the data exists in memory, the database query never runs. If not, WordPress queries the database, stores the result, and serves it from cache on the next request.
This matters more as your site grows. A single page load on a membership site might trigger 200+ database queries. Object caching can cut that to under 50.
What object cache actually stores
Object cache doesn’t store rendered HTML. It stores discrete pieces of data WordPress requests repeatedly:
- Post metadata: custom fields, featured image IDs, post status
- Taxonomy terms: categories, tags, and custom taxonomies assigned to posts
- User data: roles, capabilities, profile fields
- Options table entries: site settings, plugin configurations
- Transients: time-limited data stored by plugins (API responses, remote file checks)
Page caching—what most CDNs and caching plugins do—stores the final HTML output. Object caching operates one layer deeper, at the data-retrieval level. That’s why you often run both: page cache for anonymous visitors, object cache for logged-in users and admin requests.
Redis and Memcached are the two dominant backends. Redis persists data to disk and survives server restarts; Memcached lives entirely in RAM and flushes on reboot. For solo operators, Redis is the safer default. Most managed WordPress hosts offer it as a toggle in the dashboard.
When purging object cache breaks workflows
Flushing object cache is a common troubleshooting step. You update a plugin, something looks wrong, you clear all caches. That works—until it doesn’t.
Some plugins store non-regenerable data in transients. If you flush the cache mid-process, the plugin loses track of where it was. I’ve seen this break:
- Bulk import tools that cache progress state between batches
- OAuth tokens stored as transients (rare, but it happens)
- Membership plugins tracking trial eligibility windows
If a process starts behaving erratically after a cache flush, check whether the plugin documentation warns against it. WP-CLI’s wp cache flush is instant and irreversible—there’s no undo.
A safer alternative: flush selectively. Most object cache plugins let you clear specific cache groups (users, posts, terms) instead of nuking everything. WP Rocket and LiteSpeed Cache both expose group-level controls in their dashboards.
When object cache doesn’t help
Object caching speeds up repeated queries. If your site serves mostly anonymous traffic and you’re already using page caching, object cache adds minimal benefit—the page cache serves HTML before WordPress even boots.
It shines in three scenarios:
- Membership or user-specific content: logged-in users bypass page cache, but object cache still cuts database load
- High-traffic admin areas: dashboard requests hit the database hard; object cache reduces query time
- WooCommerce or other plugin-heavy builds: plugins query metadata constantly; caching eliminates redundant lookups
If you’re running a simple blog with static pages and no user accounts, object cache won’t make a perceptible difference. Your hosting plan’s resources matter more.
Configuration detail most hosts skip
Default object cache configurations use the same Redis or Memcached instance for every site on a multisite network. That means a cache flush on Site A also purges Site B’s data.
If you’re running multiple sites—even just a staging and production environment—set unique cache key prefixes. In Redis, that’s the WP_CACHE_KEY_SALT constant in wp-config.php:
define('WP_CACHE_KEY_SALT', 'mysite_prod');
This ensures staging flushes don’t touch production cache, and vice versa. Managed hosts sometimes set this automatically. If you’re on a VPS or managing your own stack, you configure it manually.
One more detail: object cache doesn’t replace database optimisation. If you’re running slow queries, caching only hides the symptom. Use Query Monitor to log what’s actually hitting the database, then optimise the queries or add indexes. Cache speeds up reads; it can’t fix inefficient writes or missing foreign keys.
Have a caching setup that doesn’t fit the standard advice? Reply and tell us what you’re running—we read every response.