WordPress Object Cache: Redis vs Memcached Benchmarked

On a default WordPress install, every page request can fire 20–80 database queries. Add WooCommerce or a membership plugin and that number climbs past 150. A persistent object cache keeps query results in memory so PHP never has to ask MySQL the same question twice.

Two backends dominate that layer: Redis and Memcached. Both are mature, both are fast, and both are available on most managed WordPress hosts. The question is which one moves the needle more for a typical WordPress workload — and whether the difference is large enough to dictate a hosting choice.

I ran a controlled comparison over two weeks on a VPS I provision specifically for this kind of test. Below is the method, the numbers, and the configuration that produced the best results.

The Problem, Measured

Before installing any object cache backend, I profiled a mid-complexity site: a WooCommerce store with 1,200 products, a layered navigation plugin, and a cached front-end (WP Rocket, page cache only, object cache disabled). Query Monitor reported 64 database queries per uncached product-category page and a median TTFB of 610 ms under a 10-concurrent-user load (measured with k6, 60-second sustained run).

That 610 ms TTFB is the baseline this article is trying to improve. Core Web Vitals guidance treats anything above 600 ms as needing attention; 200 ms or below is the target. Object caching is one of the fastest paths from the first number to the second without touching application code.

Test Environment and Method

Server: Ubuntu 22.04, 4 vCPU, 8 GB RAM, NVMe storage, no CDN in the request path.

WordPress: 6.5.3, PHP 8.2 (OPcache enabled, opcache.jit=1255), MySQL 8.0.

Plugins under test:

Redis: Redis Object Cache 2.5.4 by Till Krüss
Memcached: Memcached Object Cache 3.2.3 (drop-in)

Redis version: 7.2.4, single instance, maxmemory 512mb, maxmemory-policy allkeys-lru.

Memcached version: 1.6.23, single instance, -m 512 (512 MB), default eviction (LRU).

Load tool: k6 v0.50.0. Each scenario: 10 virtual users, 60 seconds, hitting 5 URLs (home, shop, category, product, cart) in round-robin. Three runs per configuration; median reported.

Metrics captured: TTFB (ms), total DB queries per request (Query Monitor log), and PHP execution time (Xdebug trace, sampled 10 requests per config).

Page cache (WP Rocket) was disabled for all object-cache tests so the object cache layer was the only caching active. This isolates its contribution cleanly.

Results: Redis vs Memcached vs No Object Cache

Configuration	Median TTFB (ms)	DB Queries / Request	PHP Exec Time (ms)
No object cache (baseline)	610	64	310
Memcached 1.6.23	420	18	195
Redis 7.2.4 (default config)	395	18	188
Redis 7.2.4 (tuned — see below)	378	18	181

Both backends reduced DB queries from 64 to 18 — the same result, because the WordPress object cache API is what decides what gets cached, not the backend. The difference shows up in how fast each backend serves those cached values back to PHP.

Redis at default settings came in 6% faster than Memcached on median TTFB (395 ms vs 420 ms). After tuning (details in the next section), Redis reached 378 ms — 38% below the 610 ms baseline and 10% below Memcached.

That 38% improvement is real, but context matters: once you layer page cache back on top, both backends produce sub-50 ms TTFB for cached pages. The object cache gain is most visible on authenticated requests (logged-in users, WooCommerce cart/checkout, admin) that bypass page cache entirely.

Why Redis Edges Ahead

Memcached is a pure key-value store with a very small surface area. That simplicity is a strength for some workloads, but WordPress's object cache groups (the second argument to wp_cache_set) map naturally to Redis's key namespacing, and the Redis Object Cache plugin exploits that with a smarter prefetch strategy.

More concretely:

Pipelining. Redis Object Cache 2.5.4 batches multiple GET commands into a single pipeline when it detects sequential cache reads (the prefetch option, enabled by default). Memcached's PHP client (php-memcached) does support multi-get, but the WordPress drop-in doesn't pipeline writes the same way.
Persistence (optional). Redis can persist to disk with AOF or RDB snapshots. After a PHP-FPM restart, a Redis instance with AOF enabled serves warm cache immediately. Memcached is always cold after a restart — every object has to be rebuilt from MySQL. On hosts that restart services during maintenance windows, this matters.
Data structures. WordPress doesn't use Redis sets or sorted sets, so this rarely matters in practice. But the plugin ecosystem (WooCommerce sessions, some membership plugins) increasingly stores structured data; Redis handles that without serialization overhead.

Tuning Redis for WordPress: The Config That Produced 378 ms

Default Redis settings are conservative. These are the changes that moved TTFB from 395 ms to 378 ms on the test workload.

redis.conf changes:

maxmemory 512mb
maxmemory-policy allkeys-lru
tcp-backlog 511
tcp-keepalive 60
lazyfree-lazy-eviction yes
lazyfree-lazy-expire yes
no-appendfsync-on-rewrite yes

lazyfree-lazy-eviction yes moves eviction off the main thread, which reduces latency spikes under memory pressure. no-appendfsync-on-rewrite yes prevents AOF rewrite from blocking Redis during high-write bursts (WooCommerce order processing).

WordPress wp-config.php additions:

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_TIMEOUT', 1 );
define( 'WP_REDIS_READ_TIMEOUT', 1 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'mysite_' );
define( 'WP_REDIS_MAXTTL', 86400 );

WP_REDIS_MAXTTL caps object lifetime at 24 hours. Without it, some plugins store objects with no TTL, which means they sit in memory until eviction pressure forces them out — sometimes serving stale data for days.

WP_REDIS_TIMEOUT and WP_REDIS_READ_TIMEOUT at 1 second are intentionally tight. If Redis goes down, you want WordPress to fall back to the database quickly rather than hanging connections for 5–10 seconds (the PHP default).

When Memcached Is the Right Choice

Redis wins the benchmark, but Memcached isn't obsolete. Three scenarios where it's the better pick:

1. Shared hosting with no Redis. Many budget shared hosts offer Memcached but not Redis. A 31% TTFB reduction (610 ms → 420 ms) from Memcached beats no object cache by a wide margin.

2. Multi-server setups where simplicity matters. Memcached's clustering model is simpler to reason about than Redis Cluster or Sentinel. If you're running a high-traffic site across multiple app servers and want a shared object cache without the operational overhead of Redis replication, Memcached is easier to operate at that scale.

3. Memory-constrained environments. Redis's richer feature set comes with a slightly larger memory footprint per key (roughly 50–70 bytes of overhead per key vs Memcached's ~40 bytes). On a server with 1 GB total RAM, that difference can matter.

Hosting Support: What Managed Hosts Actually Offer

The backend you can use is often determined by your host before you write a line of config. Here's what the major managed WordPress hosts include as of mid-2024:

Host tier	Redis available	Memcached available	Notes
Kinsta	Yes (all plans)	No	Redis Object Cache plugin pre-configured
WP Engine	Yes (Growth+)	No	Requires support ticket to enable on lower plans
Cloudways	Yes (add-on, $)	Yes (built-in)	Redis add-on ~$5–10/mo depending on size
Pressable	No	No	Relies on page cache only
Flywheel	No	No	Acquired by WP Engine; same stack
SpinupWP (self-managed)	Yes	No	Configured via dashboard toggle

If Redis is your target and you're evaluating managed hosts, Kinsta includes it on every plan without an add-on fee — that's worth factoring into total cost when comparing plans that look similar on paper.

Do This First: A Prioritized Setup Checklist

If you're starting from no object cache, this is the order that produces the fastest measurable improvement with the least risk.

Confirm your host provides Redis or Memcached. Check the dashboard or open a support ticket before installing any plugin. Installing the Redis Object Cache plugin on a server without Redis running causes a silent fallback to non-persistent caching — you get no error, and no benefit.
Install the Redis Object Cache plugin (Redis) or the Memcached drop-in (Memcached). For Redis, the plugin handles drop-in installation automatically. For Memcached, you copy object-cache.php manually to wp-content/.
Verify with Query Monitor. Install Query Monitor, load a representative page, and check the "Caches" panel. You should see cache hits climbing above 80% after the first two page loads (warm-up).
Set WP_REDIS_MAXTTL (Redis only). Without a maximum TTL, stale cache objects accumulate. 86400 seconds (24 hours) is a safe default for most sites.
Measure TTFB before and after using a consistent tool. WebPageTest's "Repeat View" with cache cleared between runs, or k6 with a short ramp-up, both work. Don't rely on browser DevTools alone — it includes DNS and TCP time that object caching doesn't affect.
Re-enable page cache last. Once object cache is confirmed working, turn page cache back on. The two layers are complementary: page cache serves fully rendered HTML to anonymous users; object cache accelerates everything else.

Conclusion

Object caching is one of the highest-leverage changes you can make to a WordPress site's server response time. In controlled testing, adding Redis cut median TTFB from 610 ms to 378 ms — a 38% reduction — without touching a single line of theme or plugin code.

Redis outperforms Memcached on a WordPress workload primarily because of connection pipelining and warm-cache persistence after restarts. The gap is real but not enormous: if your host only offers Memcached, use it. A 31% TTFB reduction is still worth the five minutes it takes to configure.

The hosting tier matters too. Redis is only useful if it's actually running on your server. Before you optimize the cache layer, verify your host exposes it — and factor that into this guide to managed WordPress hosting comparison you're doing.