WordPress Object Cache: Redis vs Memcached Benchmarked

On an uncached WordPress page load, the database can execute 40–80 queries before the first byte leaves the server. A persistent object cache cuts that number dramatically — but the choice of backend matters more than most hosting guides acknowledge. This article puts Redis and Memcached through the same staging-to-production pipeline I used when managing a 200-site agency fleet, so the numbers reflect a realistic WordPress workload rather than a synthetic microbenchmark.

What the Metric Actually Measures

Before comparing backends, it helps to be precise about what "object caching" changes. WordPress's WP_Object_Cache class stores the results of expensive operations — database queries, option lookups, term counts — in memory for the duration of a single request. A persistent object cache extends that store across requests, so the second visitor to /shop/ doesn't re-run the same 60 queries the first visitor triggered.

The two numbers I track are:

• TTFB (Time to First Byte) — measured with WebPageTest (Dulles, Virginia, cable profile, median of five runs).
• DB query count per page — read from the Query Monitor plugin (v3.16.4) on a WooCommerce shop page with 48 products, no page cache active.

Disabling the page cache isolates the object cache's contribution. If page cache is on, both backends look identical because the HTML is served from disk.

Test Environment

The staging server is a single VPS (4 vCPU, 8 GB RAM, NVMe) running Ubuntu 22.04, Nginx 1.24, PHP 8.2-FPM with OPcache enabled, and WordPress 6.5.3. WooCommerce 8.9.1 is the workload. I imported the WooCommerce sample data and added a realistic functions.php with a few custom meta queries to simulate a client site.

Redis version: 7.2.4, using the PhpRedis extension (v6.0.2) and the Redis Object Cache plugin (v2.5.2) by Till Krüss.

Memcached version: 1.6.26, using the php-memcached PECL extension (v3.2.0) and the W3 Total Cache Memcached object cache driver (v2.7.5).

Both backends were allocated 256 MB of memory. Redis was configured with maxmemory-policy allkeys-lru. Memcached uses its default slab-based LRU. No replication, no clustering — a single-node setup matching what most managed hosts actually provision.

Baseline: No Persistent Object Cache

With only the default in-memory cache (wiped on every request), the WooCommerce shop page produced:

• TTFB: 610 ms (median of five runs)
• DB queries: 74

That 610 ms TTFB is the problem statement. Core Web Vitals guidelines treat anything above 600 ms as needing improvement, and this page is right on the edge before a single visitor has been served.

Redis Results

After installing the Redis Object Cache plugin and running wp cache flush, I let the cache warm over ten page loads before recording measurements.

• TTFB: 188 ms
• DB queries: 9

The query reduction from 74 to 9 is the meaningful result. Those nine remaining queries are non-cacheable writes (cart session updates) that WordPress intentionally skips the object cache for. The 188 ms TTFB represents a 69% reduction from baseline.

Redis handled cache invalidation cleanly during a product update test: editing a product's price flushed only the relevant cache groups (posts, terms, options) without a full cache wipe, thanks to the plugin's group-based invalidation.

Memcached Results

With W3 Total Cache's Memcached driver active (object cache only, page cache disabled):

• TTFB: 214 ms
• DB queries: 9

Query count is identical — both backends intercept the same WordPress cache API calls. The TTFB gap (188 ms vs 214 ms) is modest but consistent across all five runs. The standard deviation on Redis runs was ±11 ms; on Memcached it was ±18 ms, suggesting slightly less consistent latency under the PHP 8.2 connection overhead.

Head-to-Head Comparison Table

Metric	No Cache	Redis 7.2	Memcached 1.6
TTFB (ms, median)	610	188	214
DB queries per page	74	9	9
TTFB std deviation (ms)	±31	±11	±18
Cache invalidation scope	n/a	Group-level	Full-flush risk*
Persistence after restart	n/a	Optional (AOF)	No
Multi-site support	n/a	Native	Requires prefix config
Memory overhead (256 MB alloc)	0	~14 MB used	~11 MB used

*W3 Total Cache's Memcached driver flushes the entire cache on certain object types by default. This can be tuned, but requires manual configuration.

Why Redis Edges Ahead in Practice

The 26 ms TTFB difference alone would not justify a strong recommendation. What tips the balance is operational behavior.

Cache invalidation granularity. When a WordPress cron job updates 15 products simultaneously, Memcached's default behavior in W3TC triggers a full cache flush. Redis Object Cache uses cache groups, so only the posts and terms groups are invalidated. On a busy WooCommerce store, this difference means Memcached can produce a "cold cache storm" — a burst of full database queries — after any bulk operation.

Persistence. Redis can write its dataset to disk with AOF (Append-Only File) logging. After a server restart, the object cache is warm within seconds. Memcached starts cold every time. On shared or managed hosts that restart containers frequently (some do this nightly), this matters.

Multi-site. WordPress multi-site requires cache key prefixing per blog ID. Redis Object Cache handles this automatically. Memcached drivers require manual $memcached_servers and prefix configuration in wp-config.php, which is error-prone during site migrations.

Data structure support. Redis supports lists, sets, and sorted sets. Most WordPress plugins don't use these directly, but advanced plugins (WooCommerce Subscriptions, some membership plugins) can store complex data structures more efficiently when the cache backend supports them.

When Memcached Is Still a Reasonable Choice

Memcached is not the wrong answer in every scenario.

• Shared memory across multiple PHP-FPM pools. Memcached's multi-threaded architecture can serve multiple pools from a single daemon with lower per-connection overhead than Redis in some configurations. On servers running 10+ WordPress sites from one PHP-FPM master, this can matter.
• Managed host constraints. Some managed WordPress hosts offer Memcached but not Redis (this is increasingly rare in 2024, but it exists). Using Memcached is better than falling back to no persistent cache.
• Simpler stack. If your team is already operating Memcached for another application and adding Redis introduces a new dependency to maintain, the operational cost may outweigh the 26 ms gain.

Recommended Redis Configuration for WordPress

These are the settings I apply to every site after testing. They differ from plugin defaults in a few places.

In redis.conf (or your host's Redis config panel):

maxmemory 256mb
maxmemory-policy allkeys-lru
tcp-keepalive 60
timeout 0

allkeys-lru is critical. The default noeviction policy causes Redis to return errors when memory is full, which breaks WordPress rather than gracefully degrading.

In the Redis Object Cache plugin settings:

• Enable asynchronous flushing (reduces blocking on bulk operations).
• Set connection timeout to 0.5 s. The default 1 s means a Redis failure adds a full second to every page load before PHP falls back to the in-memory cache.
• Enable cache group prefixing if running multi-site.

In wp-config.php:

define( 'WP_REDIS_TIMEOUT', 0.5 );
define( 'WP_REDIS_READ_TIMEOUT', 0.5 );
define( 'WP_REDIS_MAXTTL', 86400 ); // 24 hours

Setting WP_REDIS_MAXTTL prevents stale cache entries from surviving indefinitely on low-traffic sites where LRU eviction rarely triggers.

Do This First

Before installing either backend, confirm two things:

1. Your host actually provisions a dedicated Redis/Memcached instance. Some managed hosts advertise "Redis support" but route all tenants through a shared instance with a 32 MB memory cap. Ask for the maxmemory value. Anything below 64 MB on a WooCommerce site will evict so frequently that the cache hit rate drops below 60%, which is worse than no persistent cache at all in terms of predictability.

2. Run Query Monitor before and after. Install Query Monitor (v3.16.4 or later), load your highest-traffic page type while logged out, and record the query count. If you're already below 15 queries, your theme or a page builder is doing something unusual, and object caching will have a smaller effect than the numbers above suggest. If you're above 40, the TTFB improvement will likely be proportional to what I measured here.

The before → after query count is the single most honest signal of whether the object cache is working. TTFB can be influenced by CDN edge nodes, DNS, and TCP handshake time. Query count is a server-side fact.

Conclusion

WordPress object caching with Redis cut TTFB from 610 ms to 188 ms on a WooCommerce shop page — a 69% reduction — while dropping database queries from 74 to 9. Memcached reached the same query count but produced a 214 ms TTFB with higher variance and weaker cache invalidation behavior in bulk-update scenarios.

For most WordPress and WooCommerce sites, Redis is the more reliable choice in 2024, not because of raw speed alone, but because of how it handles the operational realities of a live site: bulk edits, server restarts, and multi-site deployments. Memcached remains viable when your host constrains your options or when you're already running it for another workload.

Either way, the first step is the same: measure your query count today, then measure it again after enabling a persistent object cache. The number will tell you whether the configuration is actually working.