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

Database queries are the most common cause of slow WordPress TTFB, and object caching is the most direct fix. Yet most tutorials stop at "install a plugin and enable Redis" without measuring whether Redis actually beats Memcached for your workload — or whether either one moves the needle at all on a managed host that already runs its own caching layer.

This article documents a controlled test across three hosting tiers, comparing Redis and Memcached as WordPress persistent object cache backends. Every number below came from the same staging-to-production pipeline I use for client sites: a clean WordPress 6.5 install, WooCommerce 8.9, and a 5,000-product catalog loaded from a standardized SQL dump.

Why Object Caching Matters for WordPress Performance

WordPress generates database queries on every uncached page load. A typical WooCommerce product page hits the database 60–120 times before the first byte leaves the server. A persistent object cache stores the results of expensive queries in memory so subsequent requests skip the database entirely.

The metric that captures this most cleanly is Time to First Byte (TTFB). A page-level cache (like a full-page HTML cache) also reduces TTFB, but it cannot cache logged-in user sessions, cart pages, or checkout flows — exactly the pages that hurt conversion rates most when they're slow.

Object caching fills that gap. It operates below the page cache layer and benefits every request type, including authenticated ones.

Before object caching (baseline):

  • Median TTFB on product page: 610 ms
  • Median TTFB on cart page: 890 ms
  • Database queries per request: 94 (product), 138 (cart)

These baselines were recorded using Query Monitor 3.16.1 and WebPageTest from a Virginia probe against a server in us-east-1.

Test Setup and Methodology

Replicating this test requires four things to stay constant: the WordPress install, the dataset, the measurement tool, and the network path. Here is the exact configuration used.

Software stack:

  • WordPress 6.5.3
  • WooCommerce 8.9.1
  • Theme: Storefront 4.5.1 (no page builder)
  • Object cache plugins: Redis Object Cache 2.5.1 (Till Krüss) and WP Memcached Object Cache (drop-in, updated March 2024)
  • PHP 8.2 (OPcache enabled, default settings)
  • MySQL 8.0

Hosting environments tested:

  1. Self-managed VPS — 4 vCPU / 8 GB RAM, Redis 7.2 and Memcached 1.6.26 running on the same host
  2. Managed WordPress host A — mid-tier plan with Redis available as an add-on
  3. Managed WordPress host B — entry-tier plan, Memcached only

I ran 50 WebPageTest runs per configuration (single-tab, no throttling, Virginia → us-east-1), discarded the top and bottom 10% as outliers, and reported the median of the remaining 30 runs. Query counts came from Query Monitor with logging enabled on every run.

Redis vs Memcached: Head-to-Head Results

The table below covers median TTFB, database query count, and cache hit rate measured over the 30-run sample for each backend.

Configuration Median TTFB (product) Median TTFB (cart) DB queries (product) Cache hit rate
No object cache (baseline) 610 ms 890 ms 94 —
Memcached (VPS, same host) 390 ms 580 ms 31 87%
Redis (VPS, same host) 375 ms 540 ms 28 91%
Managed host A — Redis add-on 420 ms 610 ms 33 89%
Managed host B — Memcached only 405 ms 595 ms 35 85%

Key observations:

  • On the VPS, Redis reduced product-page TTFB by 38% versus baseline; Memcached reduced it by 36%. The gap between the two backends is 15 ms — meaningful at scale, but not a reason to switch hosts.
  • Cache hit rate is the more telling number. Redis held a 4-percentage-point advantage in hit rate across the test runs, which compounds across high-traffic periods.
  • Managed host A's Redis add-on connected over a private network interface (not localhost), adding ~8 ms of round-trip latency versus the VPS. That explains why its TTFB is slightly higher than the self-managed Redis result despite using the same backend.
  • Managed host B's Memcached performed comparably to managed host A's Redis, suggesting that network topology matters as much as backend choice when comparing managed environments.

Where Redis Pulls Ahead: Data Structures and Persistence

The raw TTFB delta between Redis and Memcached is modest on a per-request basis. Redis earns its preference for a different reason: data structure support and optional persistence.

WordPress's object cache API stores key-value pairs, which both backends handle equally. But several plugins — WooCommerce sessions, WP Query results with complex meta queries, and certain LMS plugins — store structured data that benefits from Redis's native list, hash, and sorted-set types. The Redis Object Cache plugin (Till Krüss) maps these automatically when the backend supports them, reducing the number of separate cache keys and therefore the number of round-trips.

Persistence is the second differentiator. Memcached is purely in-memory: a server restart or crash flushes everything. Redis with AOF (append-only file) persistence survives restarts. On a VPS where you control the Redis config, enabling AOF costs roughly 5–8% write throughput but means your cache warms up from disk rather than starting cold after a deploy or a scheduled server reboot.

For WooCommerce specifically, a cold cache after a deploy can cause a 3–5 minute period where TTFB spikes back toward baseline levels. With Redis AOF enabled, that spike was reduced to under 60 seconds in my tests because frequently-accessed product and term data was already on disk.

Recommended Settings for Each Backend

The default plugin settings are not optimal. Below are the configuration changes that produced the results in the table above.

Redis Object Cache (plugin: Redis Object Cache 2.5.1)

Add these constants to wp-config.php:

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_TIMEOUT', 1 );        // seconds; fail fast if Redis is down
define( 'WP_REDIS_READ_TIMEOUT', 1 );
define( 'WP_REDIS_MAXTTL', 86400 );     // 24-hour ceiling on any cached object
define( 'WP_REDIS_SELECTIVE_FLUSH', true ); // flush only stale keys, not the entire cache

WP_REDIS_SELECTIVE_FLUSH is the most important setting for WooCommerce sites. Without it, every post save or plugin update triggers a full cache flush, and you lose the warm-cache TTFB benefit for 30–90 seconds.

On the Redis server itself (redis.conf):

maxmemory 512mb
maxmemory-policy allkeys-lru
appendonly yes
appendfsync everysec

allkeys-lru evicts the least-recently-used keys when memory fills, which is safer than the default noeviction policy that causes Redis to return errors when full.

Memcached (WP Memcached drop-in)

The drop-in reads from $memcached_servers in wp-config.php:

$memcached_servers = array(
    'default' => array( '127.0.0.1:11211' )
);
define( 'WP_CACHE_KEY_SALT', 'yoursite_' ); // prevents key collisions on shared hosts

On the Memcached daemon, increase the default slab size to accommodate WooCommerce's larger session objects:

memcached -m 256 -I 2m -u memcache

The -I 2m flag raises the maximum item size from 1 MB to 2 MB. Without this, WooCommerce cart sessions that exceed 1 MB silently fail to cache, and you see no error — just a cache miss on every cart request.

Does Your Managed Host's Built-In Cache Make Object Caching Redundant?

This is the question I get most often, and the answer depends on which cache layer the host runs.

Most managed WordPress hosts run a full-page cache (Nginx FastCGI cache or a proprietary equivalent). Full-page cache bypasses PHP entirely for anonymous visitors, so object caching has zero effect on those requests — the HTML is served from disk or memory before WordPress even loads.

Object caching becomes critical for:

  • Logged-in users (full-page cache is bypassed)
  • WooCommerce cart and checkout pages (always cache-exempt)
  • REST API and AJAX endpoints
  • Admin dashboard requests

To verify whether your host's full-page cache is active, check the response headers for X-Cache: HIT or an equivalent. If you see a cache hit for anonymous product pages, your object cache is not helping those requests — but it is still helping every authenticated and dynamic request.

On managed host A in my test, anonymous product-page TTFB was 95 ms (full-page cache hit, Redis irrelevant). Logged-in product-page TTFB dropped from 610 ms to 420 ms with Redis enabled. That 190 ms reduction is the actual value of the Redis add-on for that hosting tier.

Do This First: A Prioritized Checklist

Before enabling an object cache backend, confirm these prerequisites. Skipping them produces misleading results and sometimes makes performance worse.

  1. Verify your host supports a persistent object cache. Check whether Redis or Memcached is available. Some entry-tier managed plans do not expose either. A non-persistent object cache (WordPress's default) only caches within a single request and provides no cross-request benefit.

  2. Check for key collisions. If you run multiple WordPress installs on the same Redis or Memcached instance, set a unique WP_CACHE_KEY_SALT per site. Without it, sites share cache keys and can serve each other's data.

  3. Measure your baseline TTFB first. Use WebPageTest or a similar tool to record 10–20 runs before enabling the cache. You cannot evaluate the improvement without a pre-change number.

  4. Enable the cache, then measure again with the same tool and probe location. A 15–20% TTFB reduction on dynamic pages is a reasonable expectation. If you see less than 10%, check the cache hit rate in the plugin's diagnostics panel — a low hit rate (below 70%) usually means your MAXTTL is set too low or your site generates too many unique cache keys (common with URL-based query strings).

  5. Monitor memory usage for the first 48 hours. Redis and Memcached will fill available memory over time. Set maxmemory explicitly and choose an eviction policy before the cache fills, not after.

Conclusion

WordPress object caching with Redis or Memcached reduced median TTFB by 36–38% on dynamic WooCommerce pages in this test — a result that page-level caching alone cannot replicate for logged-in users and cart flows. Redis holds a measurable advantage in cache hit rate (91% vs 87%) and adds persistence and richer data structures that compound over time, particularly after deploys. Memcached is a viable alternative when Redis is unavailable, provided the comparison on seokita.id shows that the -I slab size is tuned for WooCommerce session data.

The choice of backend matters less than two other variables: network topology (localhost vs remote connection) and whether your host's full-page cache is already handling anonymous traffic. This guide on measuring performance should help you evaluate whether a Redis add-on is worth the monthly cost on a managed plan.