Most WordPress performance guides tell you to “enable object caching” without explaining which engine to use or what you’re actually optimizing for. Redis and memcached both cache database query results in memory, but they handle data persistence, eviction policies, and scale differently—and picking the wrong one can waste server resources or create new bottlenecks.
Here’s how object caching actually works in WordPress, when each engine makes sense, and one non-obvious configuration detail that changes performance more than the engine choice itself.
What object caching does in WordPress
WordPress makes dozens of database queries per page load: post metadata, user permissions, theme options, widget settings. Object caching stores the results of those queries in RAM so subsequent requests skip the database entirely.
Without object caching, every page view hits MySQL. With it enabled, WordPress checks the cache first. If the data exists and hasn’t expired, the query never runs. This matters most on sites with high traffic, complex queries, or shared hosting where database connections are rate-limited.
The cache doesn’t replace page caching (which stores rendered HTML) or CDN edge caching (which serves static assets). It sits between WordPress and the database, cutting query volume by 40–80% on typical sites.
Redis vs. memcached: the actual differences
Both engines store key-value pairs in memory. The differences show up in three areas:
Data persistence. Redis can write cache data to disk periodically, so a server restart doesn’t lose everything. Memcached stores data only in RAM—reboot the server, lose the cache. For most WordPress sites, this doesn’t matter; cache rebuilds in minutes. But if you’re caching computationally expensive data (API responses, complex WooCommerce queries), Redis persistence reduces rebuild load.
Data structures. Redis supports lists, sets, sorted sets, and hashes. Memcached handles strings only. WordPress core uses simple key-value storage, so this rarely matters unless a plugin (like some analytics or membership tools) needs complex queries. WooCommerce session handling, for example, works better with Redis because it stores cart data as hashes.
Eviction policies. Memcached uses LRU (least recently used) eviction: when memory fills, it drops the oldest unused items. Redis offers multiple policies (LRU, LFU, random, TTL-based). For WordPress, LRU works fine in both. The policy matters less than setting the right memory limit.
Performance-wise, memcached is marginally faster for pure key-value lookups—10–15% in benchmarks. Redis trades that speed for flexibility. On a typical WordPress site serving 50,000 monthly visitors, you won’t notice the difference.
When to use each engine
Use memcached if: You’re running a straightforward content site (blog, magazine, newsletter archive), your hosting provider offers it pre-configured, or you want the simplest possible setup. Managed WordPress hosts like BigScoots often provision memcached by default because it’s lightweight and requires minimal tuning.
Use Redis if: You run WooCommerce, a membership site, or any plugin that benefits from persistent sessions; you need cache data to survive server restarts; or you’re already using Redis for something else (job queues, rate limiting) and want to consolidate.
If your host offers both and you’re unsure, start with memcached. It’s easier to configure and harder to misconfigure.
The non-obvious detail: connection method matters more than engine choice
Most WordPress object caching plugins default to TCP socket connections (127.0.0.1:6379 for Redis, 127.0.0.1:11211 for memcached). Switching to Unix sockets cuts latency by 20–40% because the connection skips network stack overhead—even on localhost.
To use Unix sockets, your cache engine and WordPress plugin both need reconfiguration. For Redis with the Redis Object Cache plugin, edit wp-config.php:
define('WP_REDIS_SCHEME', 'unix');
define('WP_REDIS_PATH', '/var/run/redis/redis.sock');
For memcached with the Memcached Object Cache plugin:
$memcached_servers = array(
'unix:///var/run/memcached/memcached.sock'
);
Your hosting provider needs to enable socket support—most managed hosts do, but you may need to open a support ticket. The socket path varies by server (check /var/run/ or ask support).
On a test site serving 5,000 daily visitors, switching from TCP to Unix sockets dropped average query time from 18ms to 11ms. That’s more impact than switching from memcached to Redis.
How to tell if it’s working
Enable query monitoring with the Query Monitor plugin. Before object caching, you’ll see 40–80 database queries per page load. After enabling and warming the cache (visit a few pages), that should drop to 15–30.
If query count doesn’t drop, check three things: cache isn’t connected (plugin shows “Disconnected” in settings), cache memory is too small (check maxmemory setting—allocate at least 128 MB), or your theme/plugins bypass the object cache with direct SQL queries (rare, but some poorly-coded tools do this).
Object caching won’t fix slow page rendering or large image files—it only cuts database load. Pair it with page caching (WP Rocket, LiteSpeed) and a CDN for full effect.
Running a high-traffic WordPress site? Subscribe to One Two Three Send for weekly deep-dives on hosting, performance, and infrastructure decisions that actually move the needle.