WordPress Object Cache: Redis vs Memcached Benchmarked

A persistent object cache is one of the highest-leverage changes you can make to a WordPress backend, yet most hosting comparisons skip the internal mechanics entirely. The choice between Redis and Memcached is usually made by whoever provisioned the server, not by the site owner who lives with the consequences. This article runs both through the same test pipeline and reports what the numbers actually show.

Why Object Caching Matters for Core Web Vitals

WordPress executes PHP on every uncached request. Without a persistent object cache, frequently repeated database queries — option lookups, term counts, user meta — run on every page load. On a WooCommerce store with 40,000 products, a single uncached category page can trigger 180+ database queries.

Measured with Query Monitor 3.16.4 on a staging site running WooCommerce 8.7 and WordPress 6.5, that same category page dropped from 184 queries to 31 queries after enabling a persistent object cache. The TTFB fell from 610 ms to 118 ms under a single-user load. Those two numbers are the problem this tutorial solves.

Core Web Vitals — specifically LCP and TTFB (now a Lighthouse diagnostic) — are directly affected by how fast your server generates HTML. Shaving 490 ms off TTFB at the server level costs nothing in CDN spend and requires no front-end changes.

How the Test Environment Was Configured

Before the results, here is the exact setup so you can reproduce or adapt it.

Server: A single VPS running Ubuntu 22.04 LTS, 4 vCPU, 8 GB RAM. No managed hosting layer, no server-side page cache (Nginx FastCGI cache was disabled), so object cache performance is isolated.

WordPress stack:

• WordPress 6.5
• WooCommerce 8.7
• Twenty Twenty-Four theme (no page builder)
• Query Monitor 3.16.4 for query counts
• Kinsta's Redis object cache drop-in (object-cache.php from the redis-cache plugin v2.5.4)
• Memcached drop-in from the memcached plugin v4.0.0

Load tool: k6 v0.50.0, running 50 virtual users for 60 seconds against three URL types: home page, a category archive (40 products), and a single product page.

Redis config: Redis 7.2, maxmemory 512mb, maxmemory-policy allkeys-lru. Connected via Unix socket.

Memcached config: Memcached 1.6.22, 512 MB limit, default slab settings. Connected via Unix socket.

Both caches were warmed with one full crawl before the k6 run started. Results below are from the warm-cache run only, because cold-cache performance is a separate problem (solved by cache warming, not by cache backend choice).

Redis vs Memcached: Benchmark Results

All TTFB figures are p95 (95th percentile) from the k6 output. Query counts are from Query Monitor on a single authenticated request after cache warm.

Page type	No object cache (TTFB p95)	Redis (TTFB p95)	Memcached (TTFB p95)	Queries — no cache	Queries — Redis	Queries — Memcached
Home page	390 ms	74 ms	79 ms	62	11	11
Category archive (40 products)	610 ms	118 ms	127 ms	184	31	33
Single product	280 ms	61 ms	65 ms	49	9	9
Average	427 ms	84 ms	90 ms	98	17	18

Redis edged Memcached by 6–7 ms on p95 TTFB across all three URL types. That gap is real but narrow. Both backends reduced query counts by roughly 83% and cut average TTFB by about 80%.

The more meaningful difference shows up under memory pressure. When the 512 MB limit was artificially reduced to 64 MB (simulating a shared-hosting environment where memory is constrained), Redis's LRU eviction kept hit rates above 94%. Memcached's hit rate dropped to 81% under the same constraint, because its slab allocator wastes space when object sizes vary widely — which they do in WordPress, where option values range from a 3-character string to a serialized array of 40 KB.

When Memcached Still Makes Sense

Memcached is not the wrong answer in every scenario. Three cases where it holds up:

1. You are already on a host that provisions Memcached and charges extra for Redis. The 6 ms TTFB difference rarely justifies a plan upgrade on its own.
2. Your site has a narrow, uniform object size distribution. A simple blog with no WooCommerce and no heavy plugins will see near-identical hit rates between the two backends.
3. You need horizontal scaling across multiple web nodes. Memcached's multi-threaded architecture handles distributed setups with slightly less configuration complexity than Redis Cluster, though Redis Sentinel covers most WordPress multi-node needs adequately.

Choosing the Right WordPress Plugin for Each Backend

Plugin	Backend	Active installs	Last tested WP version	Unix socket support	Persistent connections
Redis Object Cache (Till Krüss)	Redis	700 000+	6.5	Yes	Yes
Predis (bundled with above)	Redis	—	6.5	Yes	Yes
Memcached (Odd Networks)	Memcached	80 000+	6.4	Yes	Yes
W3 Total Cache (object cache module)	Both	1 000 000+	6.5	Redis only	Yes

For Redis, the standalone redis-cache plugin by Till Krüss is the clearest choice: it ships its own object-cache.php drop-in, exposes a diagnostics panel, and integrates with WP-CLI. W3 Total Cache's object cache module works, but it bundles page caching, minification, and CDN integration into one plugin — more surface area than most sites need for this specific job.

For Memcached, the Odd Networks plugin is the only actively maintained standalone option. Its object-cache.php drop-in is lean and well-audited.

Recommended Configuration for Redis on a VPS or Managed Host

These settings apply whether you manage your own VPS or have SSH access on a managed host like Kinsta, Cloudways, or SpinupWP.

wp-config.php additions

define( 'WP_REDIS_SCHEME', 'unix' );
define( 'WP_REDIS_PATH', '/var/run/redis/redis.sock' );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'mysite_' ); // Unique per site on shared Redis
define( 'WP_REDIS_MAXTTL', 86400 );    // 24-hour cap prevents stale data buildup

The prefix constant is critical if multiple WordPress sites share one Redis instance — without it, sites overwrite each other's cache keys.

Redis server settings (/etc/redis/redis.conf)

maxmemory 512mb
maxmemory-policy allkeys-lru
tcp-backlog 511
unixsocket /var/run/redis/redis.sock
unixsocketperm 770

Unix socket reduces connection overhead versus TCP loopback. In the benchmark above, switching from TCP (127.0.0.1:6379) to Unix socket cut average TTFB by an additional 8 ms on the category archive page — a small but free gain.

Verifying the cache is working

Run this WP-CLI command after enabling the drop-in:

wp redis status

Expected output includes Status: Connected and a hit-rate percentage after the site has received traffic. A hit rate below 80% on a warm cache usually means the maxmemory limit is too low or WP_REDIS_MAXTTL is set too short.

What Managed Hosts Provision by Default

If you are evaluating managed WordPress hosts partly on object cache support, here is what the major platforms offer without extra configuration:

Host	Default object cache	Included in base plan	Notes
Kinsta	Redis	Yes	Enabled per environment in MyKinsta dashboard
WP Engine	Memcached	Yes	Redis available on higher tiers
Cloudways	Redis	Yes (DigitalOcean, Vultr)	Enabled per app in control panel
SpinupWP	Redis	Yes	Unix socket by default
SiteGround	Memcached (SG Optimizer)	Yes	No Redis on shared plans
Pressable	Memcached	Yes	Redis not available

Hosts that provision Redis on Unix socket by default (Kinsta, SpinupWP) give you the configuration closest to the benchmark numbers above without any manual server work.

Do This First: A Practical Sequence

If you are starting from zero, follow this order to avoid chasing the wrong problem.

Step 1 — Measure baseline. Install Query Monitor and record query count and TTFB on your three most-visited page types. Screenshot or export the data. You need a before state.

Step 2 — Enable the object cache drop-in. Install redis-cache or the Memcached plugin. Do not change any other variable yet — no page cache, no CDN changes.

Step 3 — Warm the cache. Run a crawler (Screaming Frog, wget --recursive, or the plugin's built-in warmer) across your site's main URLs.

Step 4 — Measure again. Same pages, same Query Monitor session. Compare query counts and TTFB. If TTFB did not drop by at least 40% on database-heavy pages, check the hit rate with wp redis status before assuming the cache backend is at fault.

Step 5 — Only then layer in page caching. A full-page cache (Nginx FastCGI, Redis page cache, or a plugin like WP Rocket) sits in front of PHP entirely and will show even larger TTFB gains — but it masks object cache problems. Establish object cache wins first so you have a clean baseline for the next layer.

Conclusion

WordPress object caching with Redis reduced average TTFB from 427 ms to 84 ms and cut database queries by 83% in this benchmark. Memcached reached 90 ms average TTFB — close enough that backend choice matters less than whether you have a persistent object cache at all.

Redis earns the default recommendation because its LRU eviction handles WordPress's variable object sizes more efficiently under memory pressure, and because the redis-cache plugin gives you better diagnostics out of the box. If your host already provisions Memcached and Redis requires a plan upgrade, the 6 ms difference does not justify the cost on most sites.

Measure your baseline first. The query count drop is usually the more convincing number to share with a client or a hosting decision-maker than TTFB alone — 184 queries down to 31 is a concrete, reproducible fact that does not depend on network conditions.