Redis and Memcached object caching for WordPress

What the object cache is

WordPress has a built-in object cache: a PHP array that holds values during a single request, filled by the wp_cache_get and wp_cache_set functions. By default it is non-persistent. Every page load calls the database for the same options, widgets, comments and post meta, because the array dies with the request.

A persistent object cache replaces the in-process array with a server that survives across requests, so the second page view can read options and other cached values from Redis or Memcached without touching MySQL. The file that does the swap is a drop-in, object-cache.php in wp-content, and WordPress loads it instead of its built-in class when it exists.

Object caching is complementary to page caching. A page cache serves static HTML; the object cache holds the dynamic values the page build uses. The WordPress performance settings article places both in the full tuning set.

Redis versus Memcached

Redis is the more common long-term choice because it is easier to tune, monitor, and later scale, and its data survives a server reboot when configured. Memcached is simpler and often already available on shared hosting, so "start with what your provider runs" is a reasonable default; you can switch later as the site grows.

The drop-in and credentials

Enabling an object cache requires three moving parts on the server: the store itself (Redis or Memcached), the PHP extension (for Redis, PhpRedis), and the drop-in object-cache.php. A plugin such as Redis Object Cache generates the drop-in from the admin, which is safer than copying a random file from GitHub.

wp-config.php needs the host and port, and if your host does not run Redis on the default port, the constants go in before the "stop editing" line:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_CACHE_KEY_SALT', 'my-site:'); // unique per install

WP_CACHE_KEY_SALT is not cosmetic. Two WordPress installs sharing one Redis will collide on keys and serve each other's data; a salt separates the namespaces, and its absence is a classic "site B shows site A's settings" bug.

The eviction trap

Redis ships with noeviction as the default maxmemory-policy, which means it stops accepting writes when memory fills. For a cache that is the worst configuration, because every wp_cache_set starts returning false and WordPress falls back to MySQL, and the site suddenly slows exactly when the cache should be helping.

Set maxmemory-policy allkeys-lru (or allkeys-lfu) for a caching workload, via maxmemory for a ceiling. The same advice applies to Memcached's -m limit: it keeps its own slab eviction, but an undersized memory limit thrashes anyway.

Check the change

After enabling the drop-in, the admin (or wp redis status when the plugin supports it) should report connected. Inspect a page re-load and a load-test: object cache reads drop, MySQL queries drop, and TTFB drops for template-heavy pages. Then load the login page and a front page to confirm nothing broke, because a bad constant or a stale drop-in shows up as errors there first.

Fixing a cache that appears enabled but does not work usually means the drop-in versus the extension mismatch: the wrong PHP module, a wrong host, or the extension installed but the server not restarted. Redis vs the wp-cron troubles are unrelated; a cron problem is never fixed by caching.

Prevention

Test the object cache on staging with the same constants and the same Redis config first, keep a unique key salt, set the eviction policy to LRU, and store the exact wp-config.php block in your deployment notes so a server move does not silently start sharing a namespace. This is the highest-leverage WordPress performance change you can make, and also the easiest one to get wrong: a bad config means the database handles every request again.