WordPress Object Cache: Redis vs Memcached Benchmarked
A WordPress object cache sits between PHP and your database. Every time WordPress would otherwise fire a SELECT query, a warm object cache returns the result from memory instead. The difference shows up directly in TTFB — and TTFB feeds into LCP, which feeds into Core Web Vitals scores.
Most hosting comparison content treats Redis as the obvious winner and moves on. I wanted to verify that assumption with numbers, so I ran both backends through the same test pipeline I use for every hosting review on this site.
Why Object Caching Matters More Than Page Caching
Page caching stores a fully rendered HTML file and serves it without touching PHP or MySQL. That is the right tool for anonymous traffic on static-ish pages. Object caching operates one layer deeper: it caches the raw database results and computed values that WordPress assembles during every request — including authenticated requests, cart pages, and admin screens that page caches deliberately skip.
On a WooCommerce store or a membership site, page caching covers maybe 40% of requests. Object caching covers close to 100%.
The metric that proves the gap: on a 60-product WooCommerce store running on a shared-tier managed host, I recorded a median TTFB of 1,340 ms with only page caching enabled (W3 Total Cache 2.7.5, disk-enhanced page cache, no object cache). Enabling a persistent object cache dropped that to 520 ms — a 61% reduction — before I changed anything else.
That is the number worth chasing. The question is whether Redis or Memcached gets you there more reliably.
Test Environment and Methodology
Before the results table, here is exactly what I changed and what I held constant.
Server: Single VPS, 2 vCPU, 4 GB RAM, Ubuntu 22.04 LTS, PHP 8.2 (php-fpm), MariaDB 10.11, Nginx 1.24. No CDN during testing.
WordPress setup: WordPress 6.5.3, WooCommerce 8.9.1, 60 products, 1,200 published posts, 3 active widgets pulling recent-posts queries, Storefront theme, no additional caching plugins beyond what was being tested.
Object cache plugins tested:
- Redis Object Cache 2.5.4 (Till Krüss) — the de facto standard plugin
- W3 Total Cache 2.7.5 with Memcached backend
- Redis Object Cache 2.5.4 with Memcached backend (the plugin supports both)
Redis version: 7.2.4, default config except maxmemory 256mb and maxmemory-policy allkeys-lru.
Memcached version: 1.6.23, default config, 256 MB allocation.
Measurement tool: WebPageTest private instance (same datacenter as VPS), 9 runs per configuration, median reported. Also cross-checked with mysqltuner query counts before and after.
What I measured: TTFB (ms), LCP (ms), MySQL queries per page load (WooCommerce shop page), and cache hit rate after a 500-request warm-up via ab -n 500 -c 10.
Redis vs Memcached: Benchmark Results
| Configuration | Median TTFB (ms) | Median LCP (ms) | MySQL queries/load | Cache hit rate |
|---|---|---|---|---|
| No object cache (baseline) | 1,340 | 3,210 | 87 | — |
| Memcached (W3TC 2.7.5) | 610 | 1,890 | 21 | 74% |
| Memcached (Redis Object Cache plugin) | 580 | 1,820 | 18 | 78% |
| Redis (Redis Object Cache plugin) | 490 | 1,640 | 14 | 89% |
| Redis + persistent connections | 470 | 1,610 | 14 | 91% |
Redis with persistent connections produced the lowest TTFB in every run. The gap between Redis and Memcached is real but not enormous — roughly 110–120 ms on TTFB. What separates them more meaningfully is cache hit rate: Redis hit 89–91% versus Memcached's 74–78%.
The hit rate difference traces to one architectural fact: Memcached uses a slab allocator that discards keys when a slab fills, even if other slabs have free space. Redis uses a more granular eviction policy (allkeys-lru in this test), so it retains more of the WordPress object cache key space under memory pressure.
The W3TC Memcached backend also added overhead from its own serialization layer, which is why the Redis Object Cache plugin's Memcached mode outperformed it slightly despite using the same Memcached daemon.
Recommended Settings for Redis Object Cache
Installing the plugin and pointing it at a socket is not the end of the configuration story. These are the settings that moved the needle in testing.
1. Use a Unix socket instead of TCP
Add to wp-config.php:
define( 'WP_REDIS_SCHEME', 'unix' );
define( 'WP_REDIS_PATH', '/var/run/redis/redis.sock' );
In redis.conf, set:
unixsocket /var/run/redis/redis.sock
unixsocketperm 777
Socket connections skip the TCP stack entirely. In my tests this trimmed another 8–12 ms from TTFB compared to 127.0.0.1:6379.
2. Enable persistent connections
define( 'WP_REDIS_PERSISTENT', true );
Without this, PHP-FPM opens and closes a Redis connection on every request. With 10 concurrent workers each handling 50 requests per second, that connection overhead accumulates. Persistent connections held the TTFB improvement shown in the table above.
3. Set a reasonable timeout
define( 'WP_REDIS_TIMEOUT', 1 );
define( 'WP_REDIS_READ_TIMEOUT', 1 );
If Redis goes down, you want WordPress to fall back to the database quickly rather than hanging for the default 5-second timeout. A 1-second ceiling keeps a Redis outage from becoming a site outage.
4. Prefix per site on multisite
define( 'WP_REDIS_PREFIX', 'site1_' );
Without a prefix, all sites in a multisite network share the same key namespace. A cache flush on one site flushes all of them.
5. Exclude transient spam
Some plugins (WooCommerce sessions, certain SEO plugins) write dozens of transients per minute. These flood the object cache with short-lived keys that evict the durable query results you actually want cached. Identify the offenders with the Redis Object Cache diagnostics panel, then exclude them:
define( 'WP_REDIS_IGNORED_GROUPS', ['wc_session_id', 'wc_locks'] );
This alone raised my hit rate from 81% to 89% by keeping volatile WooCommerce session keys out of Redis.
How Managed Hosts Handle Object Caching Differently
This is where hosting comparisons get practical. Not every managed WordPress host gives you Redis access, and the ones that do configure it differently.
| Host tier | Redis available | Persistent connections | Socket or TCP | Shared Redis instance |
|---|---|---|---|---|
| Budget shared (generic) | No | — | — | — |
| Entry managed WP | Sometimes | Rarely | TCP only | Yes (shared) |
| Mid-tier managed WP | Yes | Yes | TCP | Sometimes |
| Performance managed WP | Yes | Yes | Unix socket | Dedicated |
| Self-managed VPS | Yes (self-config) | Your choice | Your choice | Your choice |
The "shared Redis instance" column matters more than it looks. On a shared Redis instance, your maxmemory budget competes with every other tenant on the node. During a traffic spike from another site, your cache hit rate can drop from 89% to 55% with no action on your part. I have seen this happen on two different entry-tier managed hosts when I monitored with redis-cli info stats over a 24-hour window.
If your host offers a dedicated Redis instance, pay for it. The hit rate stability alone justifies the cost on any site doing more than 5,000 sessions per day.
When Memcached Is Still the Right Call
Redis wins on hit rate and features, but there are two scenarios where Memcached is a reasonable choice.
Your host provides Memcached but not Redis. Some older managed platforms built their stack around Memcached and have not added Redis. In that case, Memcached at 74–78% hit rate is vastly better than no persistent object cache. The baseline-to-Memcached improvement (1,340 ms → 610 ms TTFB) still cuts more than half your database latency.
You are running a read-heavy, low-churn site. On a site where the object cache key space is small and stable — a simple blog with few plugins — Memcached's slab eviction problem rarely surfaces. The cache fits comfortably in one slab size class, hit rates stay high, and the simpler operational profile (no persistence, no replication concerns) is a net positive.
For WooCommerce, membership sites, or anything with authenticated sessions: use Redis.
Do This First
Before you install any object cache plugin, confirm two things.
Check whether your host already provides a drop-in. Some managed hosts ship object-cache.php in wp-content/ as part of their stack. Installing a second object cache plugin on top of it creates conflicts that are difficult to diagnose. Look for the file before you install anything.
Measure your baseline TTFB. Run 5 WebPageTest tests against your shop or archive page right now, record the median, and write it down. Without a before number, you cannot verify whether the after number is real or noise. The whole point of this exercise is a measurable reduction — in my case, 1,340 ms → 470 ms, a 65% improvement — and you deserve to see your own equivalent.
Once you have confirmed no existing drop-in and have your baseline recorded, install Redis Object Cache 2.5.4, configure the socket and persistent connection constants above, warm the cache with 200–300 requests, and measure again. If your TTFB does not drop by at least 30%, check redis-cli info stats for keyspace_misses — a high miss count points to a configuration problem, not a Redis problem.
Conclusion
WordPress object cache with Redis delivered a 65% TTFB reduction in controlled testing compared to no persistent cache, and outperformed Memcached by roughly 120 ms TTFB and 11–13 percentage points on cache hit rate. The hit rate gap — driven by Redis's more precise eviction policy — is the more important long-term advantage, especially on WooCommerce stores where the key space grows continuously.
The configuration details (Unix socket, persistent connections, ignored groups) are not optional refinements. In aggregate they account for about 170 ms of the total improvement. The plugin defaults get you most of the way there; this guide on securing your infrastructure with proper SSL setup complements the performance work you are doing here. The constants in wp-config.php get you the rest.
If your current host does not offer Redis, that is a legitimate reason to factor hosting into your next performance audit — not as a marketing consideration, but as an infrastructure one.