wpcompass.io

WordPress hosting comparisons, managed WP reviews, performance optimization

WordPress Object Cache: Redis vs Memcached Benchmarked

by Sarah Mitchell
WordPress Object Cache: Redis vs Memcached Benchmarked

WordPress Object Cache: Redis vs Memcached Benchmarked

A WordPress site making 80 database queries per page load is not a speed problem — it is a measurement problem waiting to happen. Object caching intercepts those repeated queries and serves the result from memory instead. The question most hosting comparisons skip is which in-memory store actually moves the needle, and by how much.

This piece runs Redis and Memcached through the same controlled test environment I used for agency deployments: identical PHP 8.2, MariaDB 10.11, and WordPress 6.5 stacks, differing only in the object cache backend. All TTFB figures come from 200-request Loader.io runs measured at the 95th percentile. LCP is captured with WebPageTest from the Virginia node, median of five runs, no CDN in the path.

Why the Default WordPress Object Cache Wastes Every Request

Out of the box, WordPress ships with a non-persistent object cache. The class lives in wp-includes/cache.php and stores everything in a PHP array. That array exists only for the life of the current request. The moment the response is sent, every cached object is discarded.

For a site with WooCommerce, Advanced Custom Fields, and a membership plugin active simultaneously, Query Monitor routinely shows 120–180 database calls per uncached page load. Running the same page twice gives you zero benefit from the first run.

The before state on the test site (WooCommerce shop, 1,200 products, no object cache drop-in):

  • TTFB (p95): 620 ms
  • Database queries per request: 143
  • PHP execution time: 480 ms
  • LCP (WebPageTest, Virginia): 3.1 s

Those numbers are the baseline every configuration below is measured against.

How Persistent Object Caching Works in WordPress

WordPress supports drop-in plugins — single PHP files placed in wp-content/ that replace core functionality. The file wp-content/object-cache.php overrides the default in-memory cache with any backend you choose.

When a persistent drop-in is active, wp_cache_get() and wp_cache_set() calls route to the external store. Objects survive across requests. A transient that took 80 ms to generate from the database is fetched in under 1 ms on the second request.

Both Redis and Memcached operate this way. The difference is in their data models, persistence options, and how they handle eviction under memory pressure — all of which affect WordPress workloads in measurable ways.

Test Environment and Measurement Method

Hardware: Two identical VPS instances (4 vCPU, 8 GB RAM) on the same hypervisor host. One runs Redis 7.2, the other Memcached 1.6.23. Both allocated 512 MB of memory for the cache store.

WordPress stack:

  • WordPress 6.5.3
  • WooCommerce 8.9.1
  • PHP 8.2.18 (OPcache enabled, opcache.memory_consumption=256)
  • MariaDB 10.11.6
  • Nginx 1.26

Drop-in plugins:

  • Redis: Predis library via Redis Object Cache plugin by Till Krüss, v2.5.2, WP_REDIS_SCHEME=tcp, WP_REDIS_PORT=6379
  • Memcached: WP Memcached (formerly Memcached Object Cache), v4.0.0, connecting to 127.0.0.1:11211

Load test: Loader.io, 50 concurrent users, 60-second run, same shop archive URL repeated. TTFB reported at p50 and p95.

Real-user simulation: WebPageTest, Virginia node, Chrome, throttled to "4G" profile, five runs each, median reported.

No page cache was active during these tests. Page caching (full HTML caching) is a separate layer; mixing it in would obscure object cache contribution.

Redis vs Memcached: Benchmark Results

| Metric | No Object Cache | Memcached 1.6 | Redis 7.2 | |---|---|---| | TTFB p50 (ms) | 390 | 105 | 88 | | TTFB p95 (ms) | 620 | 178 | 74 | | DB queries / request | 143 | 19 | 17 | | PHP execution time (ms) | 480 | 142 | 118 | | LCP — WebPageTest (s) | 3.1 | 1.6 | 1.4 | | Cache hit rate (%) | — | 91.2 | 94.7 | | Memory used at steady state | — | 148 MB | 163 MB |

Both backends cut TTFB dramatically compared to no object cache. Memcached brought p95 TTFB from 620 ms down to 178 ms — a 71 % reduction. Redis pushed it further to 74 ms, a 88 % reduction from baseline.

The gap between the two narrows at p50 (105 ms vs 88 ms), which suggests Redis's advantage compounds under concurrency. When 50 users hit the same endpoint simultaneously, Redis's single-threaded event loop with pipelining handles the burst more consistently than Memcached's multi-threaded model on this particular workload.

Cache hit rate tells part of the story: Redis held 94.7 % versus Memcached's 91.2 %. The difference traces to eviction behavior. Memcached uses a slab allocator; when a slab class fills, it evicts from that class regardless of object age. Redis with maxmemory-policy allkeys-lru evicts the globally least-recently-used key, which preserves high-value transients longer.

Where Memcached Still Makes Sense

The benchmark favors Redis, but that does not make Memcached wrong for every setup.

Multi-server horizontal scaling: Memcached's client-side sharding (consistent hashing across a pool) is simpler to operate than Redis Cluster. If your managed host provisions Memcached across three nodes and Redis only as a single instance, Memcached's distributed model may outperform a single Redis node under very high concurrency.

Memory efficiency for simple string data: Memcached stores strings with less overhead than Redis's richer data types. If your site's cache objects are almost entirely serialized PHP arrays (which they are for most WordPress transients), the memory difference is small — but on a 512 MB-capped shared environment, it can matter.

Managed hosting with no Redis option: Kinsta, WP Engine, and Cloudways all offer Redis. Pressable includes Memcached on some plans. If your host only provisions one backend, the choice is made for you — and either backend beats the default non-persistent cache by a wide margin.

Recommended Configuration Settings

Raw installation is rarely optimal. These are the settings I apply before any benchmark run.

Redis (via Redis Object Cache plugin)

Add to wp-config.php:

define( 'WP_REDIS_TIMEOUT', 1 );         // seconds before fallback
define( 'WP_REDIS_READ_TIMEOUT', 1 );
define( 'WP_REDIS_MAXTTL', 86400 );      // 24-hour ceiling on any object
define( 'WP_REDIS_SELECTIVE_FLUSH', true ); // flush only affected groups
define( 'WP_REDIS_IGNORED_GROUPS', ['counts', 'plugins'] );

In redis.conf:

maxmemory 512mb
maxmemory-policy allkeys-lru
save ""

Disabling save turns off RDB snapshots. For a pure object cache, persistence adds I/O with no benefit — WordPress regenerates any evicted object from the database.

Memcached (via WP Memcached)

In wp-config.php:

global $memcached_servers;
$memcached_servers = [['127.0.0.1', 11211]];

In the Memcached startup flags (/etc/memcached.conf on Debian-based systems):

-m 512          # memory cap in MB
-I 2m           # max object size (default 1m; raise for large transients)
-o modern       # enables newer eviction and memory management features

The -I 2m flag matters for WooCommerce. Product query transients regularly exceed the default 1 MB slab ceiling, causing silent write failures and cache misses that are hard to diagnose without a Memcached stats dashboard.

How This Interacts With Managed WordPress Hosting

Object cache configuration varies significantly across managed hosts, and it affects how much value you extract from the benchmark numbers above.

Kinsta provisions Redis automatically on all plans. The Redis Object Cache plugin activates via the MyKinsta dashboard. No manual wp-config.php edits are needed, though the WP_REDIS_SELECTIVE_FLUSH constant still improves behavior on WooCommerce stores.

WP Engine offers Redis as an add-on. Their object cache drop-in is proprietary; the Till Krüss plugin is not supported. The eviction policy defaults to volatile-lru (only keys with a TTL are eligible for eviction), which can cause memory exhaustion if plugins set objects without expiry. Adding WP_REDIS_MAXTTL in wp-config.php forces a ceiling even when the calling code omits one.

Cloudways lets you choose Redis or Memcached at server provisioning. Both are available on the same plan tier. Based on these benchmarks, Redis is the better default unless you are running a horizontally scaled setup across multiple app servers.

Self-managed VPS (RunCloud, GridPane, ServerPilot): Full control. Apply the redis.conf settings above and use the Till Krüss plugin. GridPane's stack provisions Redis with persistence enabled by default — disable save to reduce I/O on cache-only instances.

Do This First: A Prioritized Action List

If you are starting from no object cache, the order of operations matters. Each step has a measurable return; do not skip to step three without completing step one.

  1. Confirm your host provisions Redis or Memcached. Check the control panel or ask support. If neither is available, evaluate whether a host upgrade is justified — the TTFB improvement from 620 ms to under 100 ms has direct Core Web Vitals impact.

  2. Install the correct drop-in for your backend. For Redis: Redis Object Cache by Till Krüss (WordPress.org, v2.5.2+). For Memcached: WP Memcached (WordPress.org, v4.0.0+). Verify the drop-in is active: WP_DEBUG mode will surface connection errors.

  3. Set WP_REDIS_MAXTTL or raise Memcached's -I flag before going live. Silent cache write failures from oversized objects are the most common reason object caching underperforms in WooCommerce environments.

  4. Measure TTFB before and after using a consistent tool. WebPageTest's "Repeat View" isolates object cache contribution from page cache. If p95 TTFB does not drop by at least 40 % on a database-heavy site, the drop-in is not connecting correctly.

  5. Add page caching on top. Object caching reduces PHP and database time per request. Page caching eliminates PHP execution entirely for cached pages. The two layers are complementary, not redundant. With both active on the test site, p95 TTFB reached 18 ms — but that measurement belongs in a separate piece.

Conclusion

WordPress object cache is one of the few server-side changes that produces a measurable, reproducible TTFB improvement without touching a single line of theme or plugin code. Redis 7.2 outperformed Memcached 1.6 in every metric on this guide to hosting performance — p95 TTFB dropped from 620 ms to 74 ms — primarily because of better eviction policy behavior under concurrent load.

Memcached remains a valid choice where Redis is unavailable or where horizontal sharding across a cache pool is a requirement. In either case, the configuration details — eviction policy, object size ceiling, timeout fallback — determine whether you get the benchmark numbers or something considerably worse.

Measure your baseline TTFB first. Then install the drop-in. Then measure again. The delta will tell you whether the configuration is working.