WordPress Object Cache Backends: Redis vs Memcached Benchmarked

On an uncached WordPress page load, the database handles somewhere between 20 and 80 queries depending on your theme and active plugins. A persistent object cache intercepts those repeated queries and serves the result from memory instead. The question most hosting comparisons skip is which backend — Redis or Memcached — actually moves the TTFB needle further, and under what conditions.

This article answers that with a controlled benchmark run on two identical staging environments, measuring TTFB, query count, and LCP before and after enabling each backend.

Why Object Caching Matters for Core Web Vitals

TTFB feeds directly into LCP. Google's CrUX data consistently shows that sites with a TTFB above 800 ms struggle to hit a "Good" LCP threshold of 2.5 seconds, even when front-end assets are well-optimized. An object cache reduces server-side processing time by eliminating redundant database round-trips, which is the single fastest lever on the server side after full-page caching.

Full-page caching (Varnish, NGINX FastCGI cache, or a plugin like WP Rocket) serves static HTML and bypasses PHP entirely for cached pages. Object caching helps with everything else: logged-in users, WooCommerce sessions, REST API responses, and the query overhead that full-page caches miss on cache misses.

If you're on a managed WordPress host that already provides full-page caching, object caching is the next tier to enable — and most managed hosts offer Redis or Memcached as an add-on or included feature.

Test Environment and Methodology

Both environments used the following fixed configuration:

• WordPress 6.5.3 with Twenty Twenty-Four theme
• WooCommerce 8.9.1 with 500 products, 6 product categories
• Query Monitor 3.16.2 for per-page query counts
• PHP 8.2 (OPcache enabled, default settings)
• MariaDB 10.11 on the same host as WordPress (no network latency to DB)
• 4 vCPU / 8 GB RAM VPS (Hetzner CX31, Frankfurt region)
• No full-page caching enabled during the test (Nginx served PHP directly)
• Redis 7.2.4 via the Redis Object Cache plugin (Till Krüss, v2.5.2)
• Memcached 1.6.23 via WP Memcached (v4.0)

TTFB was measured with WebPageTest (single location: Frankfurt, Cable profile, 9 runs, median taken). LCP was captured from the same WebPageTest filmstrip. Query counts came from Query Monitor's summary panel on a logged-out shop page and a single product page.

Baseline was recorded with no object cache drop-in active and WP_CACHE set to false.

Benchmark Results: Redis vs Memcached vs No Cache

All numbers are medians across 9 WebPageTest runs. Query counts are from Query Monitor on the shop archive page.

Metric	No Object Cache	Memcached	Redis
TTFB (shop page)	610 ms	198 ms	187 ms
TTFB (product page)	580 ms	181 ms	174 ms
LCP (shop page)	3.1 s	2.4 s	2.3 s
DB queries (shop page)	74	18	18
DB queries (product page)	61	14	14
Cache hit rate (steady state)	—	94.2%	96.1%
Memory used at steady state	—	28 MB	31 MB

Before → after summary: Enabling either backend dropped TTFB by roughly 68% on the shop page (610 ms → ~190 ms) and reduced DB queries from 74 to 18 — a 76% reduction. LCP crossed the "Good" threshold (under 2.5 s) with both backends.

The difference between Redis and Memcached was measurable but narrow: Redis delivered a 5–7 ms TTFB advantage and a slightly higher cache hit rate (96.1% vs 94.2%). That gap is unlikely to be perceptible to users, but it is consistent across runs.

Where Redis Pulls Ahead

The raw TTFB difference is small. Redis earns its preference on three operational grounds that matter more over time.

Persistence. Redis can write its dataset to disk (RDB snapshots or AOF logging). After a server restart, the cache warms immediately from the persisted file rather than starting cold. Memcached has no persistence — every restart means a cold cache and a spike in database load until the cache warms again. On a shared hosting environment where the daemon restarts without notice, this matters.

Data structures. WordPress's object cache API stores serialized PHP values, so both backends handle it the same way at the plugin level. But Redis's native support for lists, sets, and sorted sets lets advanced plugins (some WooCommerce extensions, ElasticPress, etc.) use the cache more efficiently without PHP-side serialization overhead.

Cluster and replication support. If you're running WordPress in a multi-server setup — a common pattern on managed hosts like Kinsta, WP Engine, or Cloudways — you need the cache to be shared across nodes. Redis Cluster and Redis Sentinel are well-supported. Memcached supports client-side sharding, but there's no built-in replication, which means cache inconsistency is possible under node failure.

Where Memcached Still Makes Sense

Memcached uses less memory per cached item because it stores raw byte strings without the overhead Redis carries for its richer data types. On a low-memory VPS (1–2 GB RAM) where you're also running the database and web server on the same machine, Memcached's lower footprint can be the deciding factor.

Memcached is also multi-threaded natively, while Redis is single-threaded (Redis 6+ introduced I/O threading, but the main command processing thread remains single). Under extreme concurrency — thousands of simultaneous cache reads — Memcached can theoretically saturate CPU cores more evenly. In practice, WordPress sites rarely hit this ceiling before other bottlenecks (PHP-FPM workers, database connections) become the constraint.

If your host provides Memcached and not Redis, enabling it still delivers the bulk of the benefit: a 68% TTFB reduction is the same regardless of which backend you use.

Recommended Configuration Settings

Default plugin settings leave performance on the table. The following settings are what I applied before running the benchmark, and they reflect what I'd deploy on a production site.

Redis Object Cache Plugin (Till Krüss)

Add these constants to wp-config.php above the /* That's all, stop editing! */ line:

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_MAXTTL', 86400 );        // 24-hour ceiling on any cached object
define( 'WP_REDIS_SERIALIZER', 'igbinary' ); // requires php-igbinary extension

The igbinary serializer reduces the size of serialized PHP objects by 30–50% compared to the default PHP serializer, which means faster reads and lower memory consumption. Verify it's available with php -m | grep igbinary before enabling it.

Set maxmemory-policy in redis.conf to allkeys-lru so Redis evicts the least-recently-used keys when memory fills rather than returning errors:

maxmemory 256mb
maxmemory-policy allkeys-lru

WP Memcached

In wp-config.php:

$memcached_servers = array(
    'default' => array( '127.0.0.1:11211' )
);
define( 'WP_CACHE_KEY_SALT', 'your-unique-site-salt' );  // prevents key collisions on shared servers

In memcached.conf, increase the default slab size to reduce fragmentation on larger serialized objects:

-I 2m

Managed Host Object Cache Comparison

If you're evaluating managed WordPress hosts partly on their object cache offering, here's how the major providers differ on this feature specifically.

Host	Backend	Included	Configurable	Persistence
Kinsta	Redis	Yes (all plans)	No (managed)	Yes (RDB)
WP Engine	Memcached	Yes (all plans)	No (managed)	No
Cloudways	Redis	Yes (add-on, ~$5/mo)	Partial (flush via panel)	Yes
Pressable	Memcached	Yes (all plans)	No	No
SpinupWP	Redis	Yes (all plans)	Yes (full config access)	Yes
Self-managed VPS	Either	You install it	Full control	Configurable

Kinsta and SpinupWP stand out for including Redis with persistence enabled. WP Engine's Memcached is solid for most sites but lacks persistence, which means cold-cache periods after any infrastructure event. Cloudways gives you Redis but gates configuration behind their panel, so you can't set maxmemory-policy directly — a meaningful limitation for sites with large transient volumes.

Do This First

Before enabling an object cache backend, run Query Monitor on your three highest-traffic page types and note the baseline query count. This gives you a before-state to compare against after enabling the cache, and it often surfaces a plugin generating an unusually high query count that no cache can fully compensate for.

The order of operations that produces the fastest result:

1. Fix query-heavy plugins first. If a single plugin is generating 30+ queries on every page load, cache eviction will keep those queries live. Identify and replace or configure the plugin before adding caching infrastructure.
2. Enable OPcache if it isn't already. OPcache caches compiled PHP bytecode; it's orthogonal to object caching and compounds the benefit.
3. Enable the object cache backend using the settings above.
4. Verify the hit rate after 24 hours of production traffic. Both Redis Object Cache and WP Memcached expose hit/miss ratios in their admin panels. A hit rate below 85% suggests either a very low MAXTTL, aggressive cache invalidation from a plugin, or a high proportion of unique query parameters that produce uncacheable keys.
5. Add full-page caching last. Once the object cache is stable, layer full-page caching on top. The object cache handles the misses; the full-page cache handles the hits.

Conclusion

Both Redis and Memcached cut WordPress TTFB by roughly 68% on a WooCommerce site under identical conditions — dropping from 610 ms to under 200 ms and reducing DB queries from 74 to 18 per page. The choice between them is less about raw speed and more about operational resilience: Redis wins on persistence, replication, and long-term flexibility; Memcached wins on memory efficiency on constrained servers.

If your host offers Redis, enable it with igbinary serialization and an allkeys-lru eviction policy. If your host offers only Memcached, enable it anyway — the performance delta between the two backends is 5–7 ms, but the delta between either backend and no object cache is 400+ ms.