WordPress Object Cache: Redis vs Memcached Benchmarked

Every managed WordPress host markets "built-in caching" as a selling point. What that phrase usually hides is a choice between two very different object cache backends — Redis and Memcached — and that choice has measurable consequences for TTFB, database load, and LCP scores under real traffic.

This article documents a controlled comparison run on two identical staging environments: same WordPress 6.5 install, same Twenty Twenty-Four child theme, same WooCommerce 8.9 product catalog (412 products), same PHP 8.2 / MariaDB 10.11 stack. The only variable changed between test runs was the object cache driver.

Why Object Caching Matters More Than Page Caching

Page caching serves a pre-built HTML file and skips PHP entirely. That is fast, but it only works for anonymous visitors. Once a user logs in, adds a product to a cart, or hits a personalized page, page cache is bypassed. Object caching operates one layer deeper: it stores the results of database queries and PHP computations in memory so WordPress can retrieve them without hitting MariaDB again.

On a WooCommerce store with logged-in customers, a product page can trigger 80–120 individual database queries per load. With a warm object cache, that number drops to 8–15 lookups against an in-memory store. The difference shows up directly in TTFB.

Baseline TTFB measured over 200 requests with no object cache enabled: 487 ms (median, via k6 load test, 20 concurrent virtual users).

How the Test Was Structured

All tests ran on a bare-metal VPS with 8 vCPUs, 16 GB RAM, and NVMe storage — no shared-hosting noise. The load generator (k6 v0.50.0) ran on a separate machine on the same local network to eliminate WAN latency.

Each scenario:

Warm the cache with 50 silent requests.
Run 200 measured requests at 20 VUs.
Record median TTFB, p95 TTFB, and total DB query count via Query Monitor 3.16.1.
Flush, repeat twice, average the three runs.

Redis version: 7.2.4, connected via Unix socket, using the redis PHP extension (not Predis). Drop-in: WP Redis 1.0.0 (Pantheon's plugin).

Memcached version: 1.6.23, connected via Unix socket, using the memcached PHP extension. Drop-in: WP Object Cache from the Memcached Object Cache plugin (2.0.0).

Allocated memory was set to 256 MB for both backends. Persistence was enabled on Redis (AOF, appendfsync everysec). Memcached has no native persistence.

Benchmark Results: Redis vs Memcached

Metric	No Cache	Memcached 1.6.23	Redis 7.2.4
Median TTFB (ms)	487	201	106
p95 TTFB (ms)	743	318	149
DB queries per page load	94	11	9
Cache hit rate (warm)	—	91.4%	96.8%
Memory used at steady state	—	38 MB	41 MB
Supports persistence	No	No	Yes
Supports pub/sub	No	No	Yes
Cluster/replication native	No	Yes (client-side)	Yes (native)

The headline number: Redis delivered a 106 ms median TTFB against Memcached's 201 ms — a 47% gap on the same hardware, same WordPress install, same traffic pattern.

That gap is not primarily about raw memory access speed. Both backends are fast enough that latency is negligible at the hardware level. The difference comes from two places:

Data structure support. Redis natively stores sorted sets, hashes, and lists. WordPress transients that store arrays or serialized objects map more efficiently onto Redis data structures. Memcached serializes everything to a flat string and deserializes on read, adding CPU overhead per lookup.
Cache hit rate. Redis hit 96.8% versus Memcached's 91.4%. Memcached uses a slab allocator that can waste memory on size mismatches, causing earlier evictions. Redis's more flexible memory model kept more keys alive longer under the same 256 MB ceiling.

When Memcached Is Still a Reasonable Choice

The numbers favor Redis, but Memcached is not obsolete. Three scenarios where it remains defensible:

Multi-server horizontal scaling without Redis Cluster. If your infrastructure already runs multiple web nodes sharing a Memcached pool via client-side consistent hashing, adding Redis Cluster has an operational cost that may outweigh the TTFB improvement — especially if your TTFB is already under 200 ms.

Hosts that don't offer Redis. Several entry-level managed WordPress hosts provide Memcached but not Redis. A 91.4% cache hit rate is still a 5× reduction in database queries compared to no object cache at all. The comparison is Redis vs Memcached, not Memcached vs nothing.

Pure key-value workloads with very large values. Memcached handles values up to 1 MB per key by default (configurable). Redis's default max value is 512 MB, but for simple string storage at high concurrency, Memcached's threading model can be more predictable under extreme parallelism (1000+ concurrent connections).

For most WordPress sites — including WooCommerce stores, membership sites, and high-traffic blogs — none of these exceptions apply. Redis is the better default.

Recommended Redis Configuration for WordPress

Installing the plugin and pointing it at a Redis instance is not enough. These are the configuration changes that moved the needle in testing.

1. Use a Unix Socket, Not TCP

Default Redis connections go over TCP (127.0.0.1:6379). Switching to a Unix socket removes the 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' );

This change alone reduced median TTFB by 11 ms in the test environment (117 ms → 106 ms).

2. Set a Reasonable `maxmemory` and Eviction Policy

maxmemory 256mb
maxmemory-policy allkeys-lru

allkeys-lru evicts the least-recently-used key across all keyspaces when memory is full. For WordPress, this is more appropriate than volatile-lru (which only evicts keys with a TTL set), because many WordPress transients are stored without expiry.

3. Disable Transparent Huge Pages on the Host

Redis's documentation flags this and it is consistently overlooked. THP causes latency spikes under memory pressure.

echo never > /sys/kernel/mm/transparent_hugepage/enabled

Add to /etc/rc.local to persist across reboots.

4. Set a Global Cache Prefix per Environment

If you run staging and production on the same Redis instance (common on single-VPS setups), a missing prefix means staging writes corrupt production cache.

define( 'WP_REDIS_PREFIX', 'prod_' );

5. Enable Selective Group Exclusions

Some WordPress cache groups should not be stored in Redis — particularly groups that are request-specific and would never be reused. The WP Redis plugin allows exclusions:

define( 'WP_REDIS_IGNORED_GROUPS', ['counts', 'plugins', 'themes'] );

Excluding these groups reduced Redis memory usage by 9 MB in the test environment without affecting the hit rate.

How This Affects Core Web Vitals

TTFB is an input to LCP, not the whole story. To close the loop, WebPageTest (Dulles, Cable, 3 runs) measured LCP on the WooCommerce product listing page after each configuration.

Configuration	LCP (median, ms)	TTFB (ms)
No object cache	3,840	487
Memcached (default config)	2,210	201
Redis (default config)	1,490	117
Redis (tuned config above)	1,310	106

LCP dropped from 3,840 ms to 1,310 ms — a 66% reduction — moving the page from a failing Core Web Vitals score into the "needs improvement" band. Crossing into "good" (LCP under 2,500 ms) happened at the Memcached stage, but the tuned Redis config created meaningful headroom for additional front-end optimization.

Note that LCP is also affected by image optimization, render-blocking resources, and CDN placement. Object caching improves the server-side component; it does not fix a 400 KB hero image.

What Managed Hosts Actually Provide

This is where the hosting comparison angle becomes concrete. Most managed WordPress hosts advertise caching without specifying the backend. Based on published documentation and support confirmations at the time of writing:

Host tier	Object cache backend	Unix socket available	Persistence
Kinsta (all plans)	Redis	Yes	No (managed)
WP Engine (Growth+)	Memcached	No	No
Cloudways (all plans)	Redis	Configurable	Yes
Pressable (all plans)	None documented	N/A	N/A
Flywheel (Growth+)	Memcached	No	No

This table reflects documentation and support ticket responses — configurations change, and you should verify the current state with each host before making a decision. The key question to ask any managed host: "Is object caching Redis or Memcached, and is it on a Unix socket?"

Do This First

Before tuning Redis configuration or evaluating hosts, confirm whether object caching is active at all. Query Monitor's "Queries" panel shows total database queries per page load. If you see more than 50 queries on a cached page load, object caching is either disabled or not working.

The fastest path to a measurable improvement:

Install Query Monitor and record your current DB query count on a representative page.
If your host provides Redis, install WP Redis, drop in the object-cache.php file, and reload.
Check Query Monitor again. A working object cache should cut queries by 80–90%.
If query count did not drop, check WP_REDIS_DISABLED is not set to true in wp-config.php and confirm the Redis service is running (redis-cli ping).
Once confirmed working, apply this guide to the Unix socket and eviction policy settings above.

The before → after on this sequence in the test environment: 94 DB queries → 9 DB queries, 487 ms TTFB → 106 ms TTFB. That is the kind of change that shows up in field data within a few days of Search Console latency averaging.

Object caching is not a set-and-forget configuration. Monitor your Redis memory usage weekly. If used_memory is consistently above 80% of maxmemory, either increase the allocation or audit which plugins are writing large or redundant transients — a separate investigation worth its own benchmark run.