WordPress Object Cache: Redis vs Memcached Benchmarked

A WordPress object cache sits between PHP and the database, storing the result of expensive queries in memory so the next request skips the SQL round-trip entirely. Most managed WordPress hosts advertise some form of it, but the implementation details vary enough that "object caching enabled" can mean anything from a modest 12 ms TTFB improvement to a 60 ms one.

This piece tests Redis and Memcached head-to-head on the same WordPress stack, using the same WooCommerce-sized dataset, so you can decide which backend is worth requesting from your host — or configuring yourself on a VPS.

Why Object Caching Matters More Than Page Caching

Page caching stores a fully rendered HTML file and serves it without touching PHP at all. That is the right tool for anonymous traffic on static-ish pages. Object caching solves a different problem: it reduces database round-trips for logged-in users, cart sessions, complex queries, and any request that page caching deliberately bypasses.

On a WooCommerce store with 4,000 products, a single uncached category page can fire 80–120 SQL queries. With a warm object cache, that number drops to 8–15 queries because transients, option rows, and term relationships are already in memory. The before/after metric on the test site (detailed below) was 118 queries → 11 queries on the shop archive page, measured with Query Monitor 3.16.2.

That query reduction is what drives TTFB improvement — not the cache technology itself, but how completely it absorbs repeated lookups.

Test Environment and Methodology

All measurements were taken on a self-managed Ubuntu 22.04 VPS (4 vCPU, 8 GB RAM) running:

WordPress 6.5.3
WooCommerce 8.9.1
PHP 8.3 (php-fpm, OPcache enabled, no JIT)
Nginx 1.26
MariaDB 10.11
Theme: Storefront 4.4.2, no page builder

The product catalog was seeded with 4,200 products, 38 categories, and 12 active coupons — a realistic mid-size store footprint.

Redis version: 7.2.4, using the redis PHP extension 6.0.2 and the Redis Object Cache plugin 2.5.4 in phpredis client mode.

Memcached version: 1.6.23, using the memcached PHP extension 3.2.0 and the Memcached Object Cache drop-in (object-cache.php from the WordPress.org plugin, revision checked 2024-05-01).

Baseline: No persistent object cache; WordPress default in-memory cache only (cleared on every request).

TTFB was measured with k6 0.51.0 running 50 virtual users for 3 minutes against three URLs: the shop archive, a single product page, and the cart (one item added via the REST API before the run). Each scenario was run three times; the median p95 TTFB is reported. Page caching was disabled for all runs (WP Super Cache deactivated; Nginx fastcgi_cache off).

TTFB and Query Results

The table below shows p95 TTFB in milliseconds and SQL query count per page load at 50 concurrent users.

Page	Baseline TTFB	Redis TTFB	Memcached TTFB	Baseline Queries	Redis Queries	Memcached Queries
Shop archive	610 ms	148 ms	157 ms	118	11	13
Single product	390 ms	104 ms	109 ms	74	9	10
Cart (logged-in)	520 ms	201 ms	228 ms	96	18	22

Redis came out 6–14% faster than Memcached across all three pages. That gap is consistent, not noise — the three-run median varied by less than 4 ms per scenario.

The cart page shows the largest absolute difference (201 ms vs 228 ms). WooCommerce cart sessions involve frequent small writes to the object cache (session tokens, shipping calculations). Redis handles write-heavy patterns more efficiently in this configuration because it uses a single-threaded event loop that avoids lock contention, whereas Memcached's multi-threaded model introduces occasional mutex overhead on rapid small writes.

Where Memcached Still Has a Case

Memcached is not the wrong answer in every situation. Two scenarios favor it:

Your host only offers Memcached. A properly configured Memcached backend still cuts TTFB by 73% on the shop archive compared to no object cache. That improvement is large enough that switching hosts purely to get Redis is rarely justified on its own.
Multi-server setups with very large caches. Memcached's native consistent hashing across multiple nodes is simpler to operate than Redis Cluster for teams without Redis expertise. If your cache needs to span four or more nodes and your team is already running Memcached in other parts of the stack, operational familiarity is a real factor.

For a single-server managed WordPress host — the scenario most readers here are in — Redis is the better default.

Redis Configuration Settings That Actually Move the Needle

Installing the plugin and pointing it at a Redis socket is not the end of the tuning process. These three settings made a measurable difference in the test environment.

1. Use a Unix Socket, Not TCP

When Redis and PHP-FPM are on the same server, a Unix socket eliminates TCP stack overhead. In redis.conf:

unixsocket /var/run/redis/redis.sock
unixsocketperm 770

In wp-config.php:

define( 'WP_REDIS_SCHEME', 'unix' );
define( 'WP_REDIS_PATH', '/var/run/redis/redis.sock' );

Switching from TCP (127.0.0.1:6379) to the Unix socket reduced the shop archive p95 TTFB by an additional 11 ms in the test — a small but repeatable gain.

2. Set a Sane `maxmemory` and Eviction Policy

Without a maxmemory cap, Redis will consume available RAM until the OS starts swapping. Set a limit and choose an eviction policy that matches WordPress's access pattern (many reads, infrequent writes, no strict ordering):

maxmemory 512mb
maxmemory-policy allkeys-lru

allkeys-lru evicts the least-recently-used key across all keys when memory is full. This is preferable to volatile-lru (which only evicts keys with a TTL set) because some WordPress object cache keys are stored without a TTL and would never be evicted otherwise, leading to unbounded growth.

3. Enable Persistent Connections

The Redis Object Cache plugin supports persistent connections, which reuse the same TCP or socket connection across PHP-FPM worker requests instead of opening a new one each time. In wp-config.php:

define( 'WP_REDIS_PERSISTENT', true );

On the test VPS with 20 PHP-FPM workers, enabling this reduced the average connection setup overhead from ~1.8 ms to ~0.2 ms per request. The cumulative effect at 50 concurrent users was a 9 ms reduction in median TTFB.

How Managed Hosts Implement Object Caching (and What to Ask)

Most managed WordPress hosts that advertise object caching are running Redis on the same server as your WordPress instance, exposed via a shared Redis instance with key prefixing to isolate tenants. That architecture works, but it introduces one risk: noisy neighbors. If another tenant's site floods the shared Redis instance with large objects, your eviction rate rises and cache hit ratio drops.

Before assuming object caching is working correctly on a managed host, check the cache hit ratio. The Redis Object Cache plugin's diagnostics panel shows this directly. A healthy ratio for a WooCommerce store with warm traffic is above 85%. Below 75% usually means the cache is too small, the eviction policy is wrong, or keys are being invalidated too aggressively.

Questions worth asking your managed host:

Is Redis shared across tenants or dedicated to my account?
What is the maxmemory allocation for my plan?
What eviction policy is set?
Is the connection via TCP or Unix socket?

Hosts that cannot answer these questions are almost certainly running a shared Redis instance with default settings — which still helps, but leaves meaningful performance on the table.

Recommended Settings Summary

Setting	Recommended Value	Reason
Connection type	Unix socket (same-server)	Removes TCP overhead (~11 ms gain in tests)
`maxmemory`	512 MB (adjust to available RAM)	Prevents swap usage
`maxmemory-policy`	`allkeys-lru`	Handles keyless WordPress cache entries
Persistent connections	Enabled	Reduces per-request connection cost
Client mode (Redis Object Cache plugin)	`phpredis`	Lower latency than Predis (pure PHP)
Cache group exclusions	`counts`, `plugins` (if needed)	Avoids caching high-churn groups that hurt hit ratio

The phpredis vs Predis choice is worth highlighting separately. The Redis Object Cache plugin defaults to phpredis if the extension is installed, and for good reason: in a tight loop of 1,000 cache reads, phpredis completed in 38 ms vs 91 ms for Predis in the test environment. If your host only supports Predis (no phpredis extension), the plugin still works, but you leave roughly 50% of the potential latency reduction on the table.

Do This First

Before changing any Redis configuration, establish a baseline with Query Monitor and a load-testing tool. The specific steps:

Install Query Monitor 3.16.2 and note the query count and total query time on your three most-visited pages while logged out and logged in.
Run a 3-minute k6 or Loader.io test at a realistic concurrent-user count and record p95 TTFB.
Enable the object cache plugin, warm the cache with one manual browse of each page, then re-run the same load test.
Compare query counts first, then TTFB. If query count dropped significantly but TTFB improvement is small, the bottleneck has shifted — PHP execution time or network latency is now the constraint, not the database.

This sequence prevents a common mistake: attributing a TTFB improvement to the object cache when the gain actually came from a coincidental server load change between test runs.

On the test site, following this sequence confirmed that Redis alone (no page cache, no CDN) moved the shop archive from 610 ms to 148 ms p95 TTFB at 50 concurrent users — a 76% reduction driven almost entirely by eliminating 107 redundant SQL queries per page load. That is the kind of result that changes whether a site stays on a shared host or needs an upgrade.

Conclusion

WordPress object cache configuration is one of the least-discussed levers in the performance stack, partly because managed hosts abstract it away and partly because the gains are invisible until you measure query counts directly. The benchmark results here show Redis edging out Memcached by 6–14% on a WooCommerce workload, with the gap widening on write-heavy pages like the cart. The configuration details — Unix socket, allkeys-lru, persistent connections, phpredis client — account for a meaningful share of that result and are worth verifying whether you manage your own server or rely on a managed host. For those running a larger operation, this guide on open source shopping cart software may also help contextualize caching decisions within your broader platform choice.

If your host supports Redis and you have not yet checked your cache hit ratio, that is the first number to pull.