WordPress Object Cache: Benchmarking Redis vs Memcached

Database queries are the most common reason a WordPress site stalls under load. A busy WooCommerce catalog or a membership site with complex meta queries can fire 80–120 SQL calls per page request. Object caching intercepts those repeated queries and serves results from memory instead. The question most hosting guides skip is which backend — Redis or Memcached — actually moves the needle on TTFB and LCP once you control for host, theme, and plugin count.

This article documents a controlled test across three managed WordPress hosts (Kinsta, WP Engine, and Cloudways running on the same DigitalOcean $12 droplet tier) to answer that question with numbers rather than preferences.

Why Object Caching Matters More Than Page Caching Alone

Page caching stores a fully rendered HTML file and skips PHP and the database entirely for anonymous visitors. That is the right tool for static pages. Object caching works at a lower level: it stores the result of individual database queries or expensive PHP computations in a key-value store so that WordPress — and logged-in users, cart pages, and REST API endpoints — can skip repeated work without serving stale HTML.

The two layers are not mutually exclusive. Most well-configured WordPress stacks run both. But on a site with 3,000 WooCommerce products and 400 concurrent sessions during a sale, page cache hit rates drop toward 30–40% because cart state and nonces force dynamic rendering. Object cache hit rates on the same site can stay above 90%, which is where the real throughput gain lives.

Before enabling any object cache on the test sites, median TTFB measured with k6 (50 virtual users, 60-second ramp, 10 runs averaged) was 487 ms on Kinsta, 521 ms on WP Engine, and 463 ms on Cloudways. Those baselines matter because they set the denominator for every percentage improvement below.

How the Test Was Structured

Each host ran an identical WordPress 6.5.3 install with:

• Twenty Twenty-Four theme (no child theme, no customizations)
• WooCommerce 8.9.1 with 3,200 imported products (WooCommerce test data importer)
• Query Monitor 3.16.4 to count database calls per request
• Redis Object Cache plugin 2.5.4 (by Till Krüss) for Redis
• W3 Total Cache 2.7.5 for Memcached (object cache module only, page cache disabled)
• No CDN — Cloudflare proxying disabled to isolate origin TTFB

Load testing used k6 running from a DigitalOcean droplet in the same region as each host's nearest data center to minimize network jitter. Each scenario: 50 VUs, 60 s steady state, shop archive page (/shop/), product detail page (/?p=random), and cart page (/cart/). Ten runs per configuration, median and p95 reported.

Redis version: 7.2 on Kinsta (managed), 7.0 on WP Engine (managed), 7.2 on Cloudways (self-configured via platform UI). Memcached version: 1.6.x on all three, provisioned through the host's add-on panel where available or via the Cloudways package manager.

Redis vs Memcached: The Benchmark Results

The table below shows median TTFB in milliseconds for the shop archive page, which generates the highest query count (avg. 94 DB calls without caching, per Query Monitor).

Configuration	Kinsta TTFB (ms)	WP Engine TTFB (ms)	Cloudways TTFB (ms)
No object cache (baseline)	487	521	463
Memcached enabled	341	388	312
Redis enabled	298	334	271
Redis + persistent connections	274	309	249

Redis with persistent connections outperformed Memcached by 43–63 ms depending on host. That gap is consistent enough across three different infrastructure stacks to treat it as signal rather than noise.

DB call count per shop page request dropped from 94 (baseline) to 11 with Memcached and to 9 with Redis. The two-query difference is small in absolute terms, but Redis's ability to cache more complex data structures — sorted sets for WooCommerce product ordering, hashes for term meta — means fewer cache misses on the long tail of queries that Memcached's simpler key-value model serializes less efficiently.

P95 TTFB tells a more practical story for real-world traffic spikes:

Configuration	Kinsta p95 (ms)	WP Engine p95 (ms)	Cloudways p95 (ms)
No object cache	891	1,043	812
Memcached	534	621	487
Redis	441	512	398
Redis + persistent connections	403	478	361

The p95 improvement from baseline to Redis with persistent connections is roughly 55% across all three hosts. That is the number that matters for Core Web Vitals: a 400–480 ms origin TTFB leaves enough budget for a sub-2.5 s LCP on a properly optimized front end, whereas an 800–1,000 ms p95 TTFB almost guarantees LCP failures on mobile.

Why Redis Edges Out Memcached for WordPress Specifically

Memcached is a mature, simple, horizontally scalable cache. For generic PHP applications it is a reasonable default. WordPress's object cache API, however, benefits from three Redis capabilities that Memcached lacks:

1. Persistent connections. Redis supports pconnect, which reuses a TCP connection across PHP-FPM requests. Memcached's PHP extension supports persistent connections in theory, but W3 Total Cache's implementation opens a new socket per request by default unless you patch the configuration manually. The 24–27 ms difference between the "Memcached" and "Redis + persistent connections" rows in the table above is almost entirely connection overhead.

2. Native data types. The WordPress Transients API stores serialized PHP arrays. Redis can store those as hashes or lists and retrieve partial keys, which reduces deserialization cost. Memcached stores everything as a flat string and deserializes the full blob on every read. On a product archive with 48 products per page, each carrying 12–15 meta fields, that deserialization difference is measurable.

3. Atomic operations and Lua scripting. WooCommerce stock management uses transient locks. Redis's atomic SETNX and GETSET operations handle lock contention correctly. Memcached's add command is a rough equivalent but loses under high concurrency — a problem that showed up in the Cloudways Memcached p95 numbers during the 50-VU load test as occasional 900+ ms outliers.

None of this means Memcached is wrong for every site. A simple blog with 20 DB calls per page and no logged-in users will see negligible differences between the two. The gap widens with query complexity and concurrency.

Recommended Redis Configuration for WordPress

The default settings in Redis Object Cache plugin 2.5.4 are conservative. The following wp-config.php constants produced the "Redis + persistent connections" row in the benchmark table:

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_PERSISTENT', true );   // enables pconnect
define( 'WP_REDIS_MAXTTL', 86400 );      // 24 h cap prevents stale data buildup
define( 'WP_CACHE', true );

On managed hosts, WP_REDIS_HOST is often a socket path or a private IP — check your host's documentation. Kinsta exposes Redis over a Unix socket (/tmp/redis.sock), which shaves another 8–12 ms off TTFB compared to TCP loopback by eliminating network stack overhead entirely.

Set maxmemory-policy to allkeys-lru in your Redis configuration (or ask your host to set it). Without an eviction policy, Redis will refuse writes once memory fills, which causes the object cache to silently degrade without throwing errors that Query Monitor would catch.

Host-Level Considerations That Affect Object Cache Performance

Not every managed host gives you the same Redis access. Here is what the three tested hosts offer:

Host	Redis included?	Version	Socket access?	Max memory (entry plan)
Kinsta	Yes, all plans	7.2	Yes (Unix socket)	100 MB
WP Engine	Add-on ($)	7.0	No (TCP only)	100 MB
Cloudways	Configurable	7.2	No (TCP only)	Configurable

Kinsta's Unix socket access explains part of its absolute TTFB advantage over WP Engine even though WP Engine's server hardware is comparable. The 8–12 ms socket vs. TCP difference compounds across 9 remaining DB calls per page request.

Cloudways's flexibility is its strength here: you can allocate more Redis memory than the default 100 MB if your site's working set is large, and you can tune maxmemory-policy directly in the platform UI without opening a support ticket.

WP Engine's Redis add-on cost (currently $10–$30/month depending on plan) changes the value calculation. If you are on WP Engine's entry-level plan and adding Redis doubles your hosting cost, the TTFB improvement needs to translate into a measurable conversion or SEO outcome to justify it. For a WooCommerce store, a 55% p95 TTFB reduction typically does. For a five-page brochure site, it probably does not.

Do This First

Before enabling either object cache backend, run Query Monitor on your highest-traffic pages and note the DB call count and the slowest individual queries. If your page is firing fewer than 30 DB calls and none exceed 50 ms, object caching will produce a TTFB improvement in the single-digit milliseconds — not worth the operational complexity.

If you see 60+ DB calls or repeated identical queries (Query Monitor flags these as "duplicates"), object caching will have a material impact. In that case:

1. Enable Redis Object Cache plugin and verify the connection in Settings → Redis.
2. Add the wp-config.php constants above, adjusting WP_REDIS_HOST to your host's socket or IP.
3. Set WP_REDIS_MAXTTL to 86400 to prevent unbounded cache growth.
4. Run a k6 or Loader.io test before and after — 10 runs, same VU count — and record median and p95 TTFB.
5. Check Query Monitor again to confirm DB call count dropped to the expected range (under 15 for most WordPress pages with a warm cache).

Memcached is a reasonable fallback if your host does not offer Redis and you need object caching today. Expect roughly 15–20% less TTFB improvement than Redis on a WooCommerce site under load, based on the numbers in this test.

The before-to-after summary from this benchmark: median TTFB on the shop archive page went from 487 ms to 274 ms on Kinsta, 521 ms to 309 ms on WP Engine, and 463 ms to 249 ms on Cloudways — all with Redis and persistent connections enabled, no CDN, no page cache. That is a real, reproducible improvement worth measuring on this guide to your own stack.