WordPress Object Cache: Redis vs Memcached Benchmarked

Database queries are usually the first bottleneck you hit when WordPress traffic climbs. A persistent object cache keeps the results of expensive queries in memory so PHP never has to ask MySQL the same question twice. The two most common backends are Redis and Memcached — and managed WordPress hosts increasingly offer one or both as a one-click add-on.

The question worth asking before you enable either: do they perform the same on a real WordPress workload, or does one consistently pull ahead?

This article documents a controlled test on a self-managed VPS (Ubuntu 22.04, PHP 8.2-FPM, MySQL 8.0, Nginx) running WordPress 6.5 with WooCommerce 8.9 active. The same twenty-product catalog and the same traffic replay were used for every run.

Why Object Caching Matters for Core Web Vitals

Server response time (TTFB) feeds directly into Time to First Byte, which is one of the diagnostic metrics Google's PageSpeed Insights surfaces alongside Core Web Vitals. A slow TTFB delays every downstream asset — fonts, images, scripts — so the LCP element loads later even if the image itself is perfectly optimized.

Before adding any object cache, the test site recorded:

• Median TTFB: 610 ms (measured with k6 at 20 concurrent virtual users, 60-second ramp)
• MySQL query count per page load: 47 (logged via Query Monitor 3.16.2)
• PHP memory per request: 28.4 MB

Those numbers are the baseline every subsequent result is measured against.

Test Environment and Methodology

Reproducibility matters more than raw numbers, so here is the exact stack:

Layer	Version / Config
OS	Ubuntu 22.04 LTS
Web server	Nginx 1.24, FastCGI cache disabled
PHP	8.2.18-FPM, OPcache enabled (256 MB)
WordPress	6.5
WooCommerce	8.9
MySQL	8.0.36, innodb_buffer_pool_size 512 MB
Redis	7.2.4, maxmemory 256 MB, allkeys-lru eviction
Memcached	1.6.23, 256 MB limit
Object cache plugin (Redis)	WP Redis 1.0.1 (Pantheon)
Object cache plugin (Memcached)	Memcached Object Cache 4.0.0
Load tool	k6 0.50, 20 VUs, 60 s steady state

FastCGI page cache was intentionally disabled. The goal was to isolate the object cache layer, not to measure full-page caching (that is a separate test worth its own article).

Each configuration ran three times. The median of the three runs is reported. Between runs, Redis and Memcached were flushed (redis-cli FLUSHALL and echo flush_all | nc 127.0.0.1 11211) and the k6 script replayed the same 200-request sequence — shop page, single product, cart, checkout — in the same ratio.

Redis vs Memcached: Benchmark Results

Metric	No cache (baseline)	Memcached 1.6	Redis 7.2
Median TTFB (ms)	610	198	183
p95 TTFB (ms)	890	312	271
MySQL queries / page	47	9	9
PHP memory / request (MB)	28.4	19.1	18.8
Cache hit rate (steady state)	—	91.4 %	93.2 %
Failed requests (200 VUs, 30 s spike)	0	3	0

Baseline → Redis: median TTFB dropped from 610 ms to 183 ms, a 70 % reduction. MySQL queries fell from 47 to 9 per page load.

Baseline → Memcached: median TTFB dropped to 198 ms, an 68 % reduction. The query count was identical at 9.

The day-to-day difference between Redis and Memcached is small — 15 ms at the median. That gap is unlikely to be perceptible to users or to meaningfully shift LCP on its own. Both backends eliminate roughly 80 % of MySQL round-trips, which is where the real win lives.

The more meaningful difference appeared during the spike test (200 virtual users for 30 seconds without warm-up). Memcached produced three failed requests; Redis produced none. That aligns with Redis's single-threaded event loop being more predictable under sudden concurrency than Memcached's multi-threaded model when the connection pool is not pre-tuned.

Where Redis Pulls Ahead of Memcached

Raw TTFB is not the only dimension worth comparing.

Persistence. Redis can write its dataset to disk (RDB snapshots or AOF logs). After a server restart, the cache re-warms from disk rather than from scratch. Memcached loses everything on restart. On a shared or managed host where you do not control restart schedules, that matters.

Data structures. WordPress itself only needs simple key-value storage, but plugins increasingly use Redis's native lists, sorted sets, and hashes. WooCommerce sessions, for example, can be stored as Redis hashes rather than as serialized PHP blobs, which reduces the size of each write. The Memcached Object Cache plugin cannot take advantage of this because Memcached only supports flat key-value pairs.

Cluster and replication support. Redis Sentinel and Redis Cluster are well-supported by WP Redis and the newer wp-redis drop-in maintained by Automattic. Memcached clustering requires client-side sharding logic that most WordPress plugins handle inconsistently.

TLS encryption. Redis 6+ supports TLS natively. Memcached's TLS support is an optional compile-time flag that many package maintainers do not enable. If your cache server is on a separate host from your web server — common on managed platforms — unencrypted Memcached traffic is a real concern.

Where Memcached Still Makes Sense

Memcached is not obsolete. On a single-server setup where persistence and clustering are irrelevant, it has two practical advantages.

Lower memory overhead per connection. Each Memcached connection consumes roughly 10–15 KB. A Redis connection with its default settings can consume 50–100 KB. On a VPS with 1 GB RAM and 50+ PHP-FPM workers, that gap adds up.

Simpler operations. Memcached has no persistence layer to configure, no replication to monitor, and no eviction policy edge cases involving sorted sets. If you are handing a server to a client who will self-manage it, Memcached's operational simplicity is a real benefit.

If your managed host offers only Memcached — several shared-infrastructure providers do — enabling it still delivers the 68 % TTFB reduction shown above. Do not skip it waiting for Redis.

Recommended Configuration for WordPress + Redis

The defaults work, but three settings materially affect WordPress performance.

1. Set maxmemory and maxmemory-policy.

Without a memory limit, Redis will consume all available RAM if cache objects accumulate. For WordPress, allkeys-lru is the correct eviction policy: it evicts the least-recently-used key when memory is full, regardless of whether the key has a TTL. The alternative, noeviction, causes Redis to return errors once memory is full — which breaks WordPress silently.

maxmemory 256mb
maxmemory-policy allkeys-lru

2. Use a Unix socket instead of TCP.

When Redis and PHP-FPM run on the same server, a Unix socket eliminates TCP stack overhead. In the test environment, switching from 127.0.0.1:6379 to /var/run/redis/redis.sock reduced median TTFB by an additional 11 ms (183 ms → 172 ms). Configure it in wp-config.php:

$redis_server = array(
    'host' => '/var/run/redis/redis.sock',
    'port' => 0,
);

And in redis.conf:

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

3. Set a global cache key prefix per site.

On a multisite or multi-tenant server, every site must use a unique prefix or cache keys collide. WP Redis reads WP_CACHE_KEY_SALT from wp-config.php:

define( 'WP_CACHE_KEY_SALT', 'mysite_prod_' );

This is also the setting to change when you want to invalidate the entire cache without flushing Redis — increment a version suffix instead.

Do This First: A Prioritized Checklist

Before tuning eviction policies or socket paths, confirm the basics are in place. The items below are ordered by impact-to-effort ratio based on the test results.

1. Verify OPcache is active. Object caching helps MySQL; OPcache helps PHP compilation. Both are necessary. Run php -r "echo opcache_get_status()['opcache_enabled'];" — it should return 1.

2. Install the correct drop-in. The object-cache.php drop-in must live in wp-content/, not in wp-content/plugins/. Many object cache plugins install it automatically on activation, but confirm with wp cache type via WP-CLI.

3. Check hit rate before tuning memory. Use redis-cli INFO stats | grep keyspace_hits to calculate hit rate after 10 minutes of real traffic. A hit rate below 80 % usually means the cache is too small or TTLs are too short, not that the plugin is misconfigured.

4. Enable Redis persistence only if you need it. AOF with appendfsync everysec adds a small write overhead. On a site with heavy write traffic (WooCommerce orders, form submissions), measure TTFB with and without AOF before committing.

5. Set WP_CACHE to true. Without this constant in wp-config.php, WordPress will not load the drop-in at all, even if the file is present.

Managed Host Considerations

Most managed WordPress hosts that offer Redis do so through a proprietary configuration panel rather than direct server access. That means you cannot always set maxmemory-policy or switch to a Unix socket. What you can control:

• Cache key salt — always set this, especially on staging environments that share infrastructure with production.
• Plugin version — keep the object cache plugin updated; WP Redis 1.0.1 fixed a connection timeout regression that affected p95 latency under load.
• Selective cache groups — some plugins register non-persistent cache groups (groups that intentionally bypass the persistent cache). Audit these with Query Monitor's Cache panel to make sure transient-heavy plugins are not defeating the object cache.

On hosts that offer both Redis and Memcached, the benchmark above gives a clear answer: choose Redis. The 15 ms median advantage is modest, but the persistence, TLS support, and spike-load reliability are worth the marginally higher memory footprint.

Conclusion

Adding a persistent object cache is one of the highest-leverage performance changes available to a WordPress site that has already optimized images and enabled OPcache. In this test, both Redis and Memcached reduced median TTFB from 610 ms to under 200 ms and cut MySQL queries from 47 to 9 per page load — numbers that translate directly into better LCP scores and lower server costs.

Redis edges out Memcached on reliability under spike traffic, cache persistence across restarts, and ecosystem support for modern WordPress plugins. Memcached remains a reasonable choice on constrained single-server setups or wherever your host does not offer Redis.

The configuration details — allkeys-lru, Unix sockets, unique key salts — are not optional polish. Each one addresses a failure mode that will surface under real traffic. Set them before you consider this guide to the object cache layer complete.