What is WordPress object cache?

Object cache stores the results of database queries in the server’s memory. This way, when WordPress needs that information again, it can quickly retrieve it from the memory cache instead of querying the database repeatedly. As a content management system, WordPress heavily relies on the database. Object caching reduces the workload on the database, leading to faster page load times.

What is the difference between object cache and page cache in WordPress?

Both caching methods improve performance, but they work differently. By understanding their differences, you can optimize your WordPress site’s speed and provide a better user experience.

WordPress Object Cache 2026: Redis, Memcached, APCu Guide

WordPress runs hundreds of database queries on a typical page load — option lookups, post metadata fetches, user capability checks, plugin settings. Without intervention, each request hits the database for the same data repeatedly. The object cache is WordPress’s mechanism for keeping frequently-accessed data in fast memory instead of repeated database lookups. Used correctly it removes the database from the critical path of most page loads; configured poorly it does nothing.

This guide covers what the object cache is, why the default WordPress configuration provides almost none of its benefit, how to enable persistent object caching with Redis or Memcached, and the operational details that determine whether object caching actually speeds your site up or quietly fails.

What This Guide Covers

What the object cache actually does inside WordPress.
Why the default (non-persistent) object cache provides limited benefit.
Persistent object caching — how it changes the picture.
The three common engines — Redis, Memcached, APCu — with neutral comparison.
Step-by-step enablement on common hosts.
Verifying that the object cache is actually working.
When object caching helps the least (and when it helps the most).
Common pitfalls and how to diagnose them.
Object caching versus page caching — different layers, different problems.
FAQs.

What the Object Cache Actually Does

The WP_Object_Cache class (reference: developer.wordpress.org) stores arbitrary key-value pairs in memory during the lifetime of a single PHP request. WordPress core uses it internally for:

Option values (get_option() results)
Post metadata (get_post_meta())
User metadata and capabilities
Term cache (categories, tags, custom taxonomies)
Comment data
Translation strings
Theme and plugin internal state

When code calls get_option('siteurl'), WordPress first checks the object cache. If present, it returns the cached value without hitting the database. If not present, it queries the database, stores the result in the object cache, and returns it. Within the same request, subsequent calls to get_option('siteurl') are served from memory.

The API for using the object cache directly:

// Set a value (group is optional but recommended for namespacing)
wp_cache_set('my_key', $expensive_data, 'mygroup', 3600); // expires in 1 hour

// Get a value
$found = false;
$data = wp_cache_get('my_key', 'mygroup', false, $found);
if (!$found) {
    $data = compute_expensive_data();
    wp_cache_set('my_key', $data, 'mygroup', 3600);
}

// Delete a value
wp_cache_delete('my_key', 'mygroup');

// Flush an entire group
wp_cache_flush_group('mygroup'); // requires persistent cache with group flush support

// Flush the entire cache
wp_cache_flush();

This API works the same whether the object cache is in-memory (default) or backed by a persistent store (Redis, Memcached). The difference is what happens between requests.

Why the Default Object Cache Is Limited

By default, WordPress uses an in-memory object cache that lives only for the duration of a single PHP request. When the request ends, the cache is discarded. The next request starts with an empty cache.

This is useful: within a single page load, repeated calls to get_option() and get_post_meta() for the same key hit the database only once. For a heavy plugin that calls get_option('plugin_settings') from twenty different functions, that’s one query instead of twenty.

What the default cache does not do: persist data across requests. If user A loads a page and the object cache stores wp_options content, user B loading the same page a millisecond later does not benefit — their request starts with an empty cache and queries the database again.

For a high-traffic WordPress site, this means the same options, postmeta, and term cache get queried from the database thousands of times per minute across thousands of concurrent requests. Each query is fast, but the cumulative load on the database is the actual bottleneck on most performance-troubled WordPress sites.

A persistent object cache changes the picture: data set with wp_cache_set() persists between requests in an external memory store (Redis or Memcached), shared across all PHP processes serving the site.

Persistent Object Caching — The Engines

A persistent object cache requires:

A backing store — Redis, Memcached, or APCu — running and accessible to PHP.
A drop-in file at /wp-content/object-cache.php that implements the wp_cache_*() functions against the chosen backing store.

The drop-in file is the key piece. WordPress core checks for the existence of /wp-content/object-cache.php early in load. If present, it loads that file instead of the default in-memory implementation, and all wp_cache_*() calls are routed through the persistent backend.

Plugins like Redis Object Cache, W3 Total Cache, LiteSpeed Cache, and Object Cache Pro provide the drop-in file and the configuration UI to set up Redis/Memcached connections.

Redis

Redis is an in-memory data structure store often described as a “key-value store on steroids.” Most production WordPress object caches use Redis.

Strengths:
– Mature, widely deployed at scale
– Supports key expiration, atomic operations, pub/sub (the object cache uses only the key-value subset)
– Excellent monitoring and observability tools (RedisInsight, redis-cli MONITOR, INFO)
– Cluster mode for horizontal scaling across multiple nodes

Operational characteristics:
– Single-threaded for commands (though network I/O is multiplexed)
– Memory is the primary constraint — sizing matters
– Persistence options (RDB snapshots, AOF) — for object cache use, persistence is optional since data is regenerable from the database

Memcached

Memcached is the older sibling — a pure key-value cache with deliberate simplicity.

Strengths:
– Simple to operate
– Multi-threaded by design (different from Redis)
– Memory-efficient for pure key-value workloads
– Wide hosting support

Operational characteristics:
– No persistence (cache is purely volatile)
– No data structures beyond keys and values (no lists, sets, sorted sets like Redis)
– LRU eviction when memory limit reached

For WordPress object cache use, Redis and Memcached are interchangeable in capability. The choice usually comes down to what the hosting environment provides.

APCu

APCu is a PHP-level in-memory cache shared across PHP-FPM workers on a single server.

Strengths:
– Zero network overhead (lives in PHP process memory)
– Simplest setup (just a PHP extension)
– Fastest access for cached data

Operational characteristics:
– Limited to a single server — cannot be shared across multiple application servers
– Cache invalidation across servers requires external coordination
– Tied to PHP-FPM process lifecycle

APCu is suitable for single-server WordPress deployments. For multi-server or container-based deployments, Redis or Memcached are required.

Step-by-Step Enablement

The exact steps depend on the hosting environment. Common patterns:

On managed hosting that supports object caching natively

Hosting providers that include Redis/Memcached in their stack typically enable the object cache with a single toggle:

Kinsta: Add-on or higher-tier plans include Redis. Enable in MyKinsta site dashboard.
WP Engine: Object Caching is bundled, enabled by default on most plans. No user action needed for the in-memory variant; Redis available on higher tiers.
Pressable: Memcached enabled site-wide automatically.
Pantheon: Object Cache Pro available as a one-click add-on on supported plans.
WP VIP: Memcached enabled by default at infrastructure level.

In these environments, no plugin installation is needed — the host has already deployed the drop-in file.

On self-managed hosting

Self-hosted WordPress requires installing the backing store and the drop-in file. A typical workflow with Redis on a Ubuntu/Debian server:

# Install Redis
sudo apt update
sudo apt install -y redis-server php-redis

# Restart PHP-FPM to pick up the extension
sudo systemctl restart php8.2-fpm
sudo systemctl enable redis-server

In wp-config.php (before the /* That's all, stop editing! */ line):

define('WP_CACHE', true);
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
// Use a unique cache prefix if multiple WordPress sites share the same Redis instance
define('WP_REDIS_PREFIX', 'mysite_');

Install the Redis Object Cache plugin from wordpress.org, activate it, and navigate to Settings → Redis. Click “Enable Object Cache” — the plugin installs /wp-content/object-cache.php (the drop-in file).

For Memcached, the parallel workflow:

sudo apt install -y memcached php-memcached
sudo systemctl restart php8.2-fpm

W3 Total Cache or LiteSpeed Cache (depending on web server) provides the Memcached drop-in.

Verifying the Object Cache Is Working

A common failure mode is enabling object caching but having it silently not work. The verification:

1. Confirm the drop-in is loaded:

ls -la /path/to/wordpress/wp-content/object-cache.php

The file should exist. If missing, the cache plugin did not install correctly.

2. Confirm WordPress is using persistent caching:

// In a custom plugin or temporary debug code:
if (wp_using_ext_object_cache()) {
    error_log('Persistent object cache active');
} else {
    error_log('Default in-memory object cache only');
}

wp_using_ext_object_cache() returns true when a drop-in is loaded.

3. Confirm the backing store is receiving traffic:

For Redis:

redis-cli MONITOR

Load a page in WordPress. You should see GET, SET, and DEL commands streaming. If no commands appear, WordPress is not connecting to Redis.

For Memcached:

echo "stats" | nc 127.0.0.1 11211

Look at get_hits and get_misses — they should increase as you load pages.

4. Confirm WP-CLI sees the cache:

wp cache type

Returns the active object cache backend (e.g., “redis”, “memcached”, or “Default”).

5. Confirm hit rate is meaningful:

After a site has been running for a while, the cache hit rate should exceed 90%. For Redis:

redis-cli INFO stats | grep -E "(hits|misses)"

For Memcached:

echo "stats" | nc 127.0.0.1 11211 | grep -E "(get_hits|get_misses)"

If hit rate is low (<50%), something is invalidating the cache too aggressively or keys are not being stored correctly.

When Object Caching Helps the Least

Object caching is not a universal speedup. Sites where the benefit is small:

Low-traffic sites (under ~5,000 page views per day). The database is not under enough load for object caching to materially affect response time.
Static content sites already aggressively page-cached. If your site serves cached HTML to most visitors via a page cache (Cloudflare, Varnish, WordPress page cache plugin), the database is barely touched even without object caching.
Sites with heavy AJAX/REST workflows where each request invalidates cache. If every page interaction triggers cache invalidation, the cache has no chance to provide repeated reads.

When Object Caching Helps the Most

The biggest beneficiaries:

WooCommerce stores under load. WooCommerce makes heavy use of post meta and option queries for product data, cart sessions, and checkout flow. Persistent object cache typically cuts checkout database query count by 50-80%.
Membership and subscription sites. Logged-in users see uncached page content, so the page cache provides little. Object cache fills the gap by reducing per-request database load.
Multi-author content sites. Editorial workflows hit the database constantly for capability checks, post meta, and revision data. Object cache improves admin dashboard responsiveness.
Sites with complex plugin stacks. Sites running 30+ plugins typically have many “expensive option” reads per page load. Object caching collapses repeated reads to single backend calls.

Common Pitfalls

1. The cache is enabled but never warmed.

A cold cache provides no benefit. After enabling object caching, the first few requests are slower (cache misses + storage overhead). The cache benefits compound only after enough traffic has populated it.

2. Cache invalidation gone wrong.

A common failure: a plugin calls wp_cache_flush() on every page load (often left over from debugging). The cache is constantly cleared, providing zero benefit. To detect: check Redis/Memcached for an extremely high flush_all rate.

3. Multiple WordPress sites sharing one Redis instance without a prefix.

Without WP_REDIS_PREFIX, multiple sites overwrite each other’s keys. Either use prefixes (preferred) or separate Redis databases per site (WP_REDIS_DATABASE 0, 1, 2, …).

4. Plugin drop-in conflicts.

Only one /wp-content/object-cache.php can exist. Installing multiple object-cache plugins causes the latest installation to overwrite the previous drop-in. Symptom: cache works, then mysteriously stops after another plugin is installed/updated. Resolution: pick one object-cache plugin, remove drop-ins from others.

5. Memory pressure causing eviction storms.

If Redis or Memcached hits its memory limit, it evicts keys (LRU). Under heavy load with insufficient memory, the cache evicts faster than it can warm — net effect is worse than no cache. Resolution: increase memory limit or use a maxmemory-policy other than the default.

6. Serialization issues with large objects.

Object caches serialize PHP values to store them. Storing huge objects (megabyte-scale arrays) is slow on both write and read. If you find yourself caching large objects, reconsider — split into smaller keys or use a different storage mechanism.

7. The drop-in file gets deleted by updates.

WordPress core updates and some hosting deployments can remove /wp-content/object-cache.php. If object caching mysteriously stops working after an update, check whether the drop-in is still present.

Object Caching vs Page Caching — Different Layers

It is common to conflate object caching with page caching. They solve different problems:

Page cache stores the final rendered HTML of a page. The next visitor gets the cached HTML without PHP or database execution. Most effective for anonymous users on content-heavy sites. Examples: Cloudflare, Varnish, WP Rocket page cache, LiteSpeed Cache page cache.
Object cache stores intermediate PHP data (option values, post meta, user data). PHP still executes, but database queries for cached data are skipped. Effective for logged-in users, dynamic pages, and any request that page cache cannot serve from HTML.

The two work together. A typical high-performance WordPress stack uses both — page cache for anonymous traffic on cacheable URLs, object cache for everything else (logged-in users, checkout, admin, REST API calls).

FAQs

Should I use Redis or Memcached for WordPress?

Either works. Choose based on what the hosting environment supports natively. If both are available, Redis has slightly more mature WordPress plugin ecosystem (Redis Object Cache plugin is more actively maintained than Memcached equivalents).

How much memory should I allocate to Redis/Memcached for WordPress?

For a typical content site: 128-256 MB is usually plenty. For a WooCommerce store under load: 512 MB to 1 GB. Monitor used_memory over a week of normal traffic and size to accommodate peak plus 30% headroom. Most hosts that include object caching pre-size adequately for their plan tiers.

Will object caching help my page load times?

If your site is database-bound (slow wp_options, slow post meta queries), yes — typically 100-500ms improvement in Time to First Byte (TTFB). If your site is bound elsewhere (slow plugins, render-blocking assets, slow hosting CPU), object caching alone will not help. Diagnose with a tool like Query Monitor before enabling.

Does object caching conflict with page caching plugins?

No. They operate at different layers. Most page caching plugins (WP Rocket, LiteSpeed Cache, W3 Total Cache) include or support object caching as a separate feature.

Will object caching break my WooCommerce store?

Generally no, when implemented correctly. WooCommerce is designed to work with object caching. The pitfall: some WooCommerce extensions cache data they should not (cart contents, session data), causing user-specific data to leak between users. This is a plugin bug, not an object caching bug — but it’s worth testing checkout flow on a staging environment before deploying persistent object caching to a production store.

What is “Object Cache Pro” and how does it differ from free options?

Object Cache Pro is a commercial Redis-based object cache by Till Krüss (the same maintainer behind the free Redis Object Cache plugin). The Pro version adds connection pooling, group flush support, deep WooCommerce integration, and dedicated support. Available bundled with some hosts (WP Engine, Pantheon) or as standalone paid subscription. Free alternatives cover most use cases; Pro adds incremental benefit at high scale.

How do I clear the object cache manually?

wp cache flush from WP-CLI clears all object cache data. Useful after database migrations, mass content updates, or when debugging cache-related issues. Note that flushing the cache temporarily slows the site as it re-populates.

Authoritative Resources

WP_Object_Cache Class Reference — WordPress core documentation
Redis documentation — Redis official
Memcached documentation — Memcached official
APCu PHP Manual — APCu official
Object Cache Pro — commercial Redis-based object cache
Redis Object Cache plugin — free Redis drop-in plugin
WordPress VIP — Object Cache — enterprise platform guidance

WordPress Object Cache: A Practical Guide to Redis, Memcached, and APCu (2026)