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 persistent object cache is one of the highest-leverage changes you can make to a WordPress backend — yet most hosting comparisons skip it entirely, focusing on page caching instead. The difference matters: page caching helps anonymous visitors, but object caching helps every request that touches the database, including logged-in users, WooCommerce sessions, and REST API calls.

The question worth asking is which backend — Redis or Memcached — actually moves the needle on TTFB and database query load, and by how much. This article answers that with a controlled benchmark rather than vendor marketing.

Why Object Caching Matters for TTFB

WordPress stores transients, user sessions, and query results in the database by default. On a site with 20–30 active plugins, a single uncached page load can trigger 40–80 MySQL queries. With a persistent object cache in place, the majority of those queries are served from RAM instead.

In my agency setup, the baseline TTFB on a mid-size WooCommerce store (WooCommerce 8.7, 4,200 products, hosted on a 4-vCPU / 8 GB VPS) was 620 ms at the 50th percentile and 1,140 ms at the 95th percentile, measured with k6 at 50 concurrent virtual users over a 5-minute window. Those numbers became the benchmark to beat.

Test Environment and Method

Before any results, here is exactly how the tests were structured so you can reproduce them.

Server: Ubuntu 22.04 LTS, 4 vCPU, 8 GB RAM, NVMe SSD, located in a single AWS us-east-1 availability zone.

WordPress stack:

  • WordPress 6.5.3
  • PHP 8.2 (PHP-FPM, OPcache enabled at 256 MB)
  • MariaDB 10.11
  • Nginx 1.24 (no full-page cache — intentionally disabled to isolate object cache effect)
  • WooCommerce 8.7

Object cache plugins tested:

  • Redis Object Cache 2.5.0 (Till Krüss) — connecting to Redis 7.2
  • W3 Total Cache 2.7.5 (Memcached backend) — connecting to Memcached 1.6.22

Load tool: k6 1.0, 50 VUs, 5-minute sustained run, targeting the shop archive page and a single product page (50/50 split).

Metrics captured: p50 TTFB, p95 TTFB, MySQL query count per request (via Query Monitor 3.15.0 with logging to file), and PHP peak memory per request.

Each configuration ran three times; the numbers below are the median of the three runs. The server was rebooted and caches were fully warmed with a 60-second ramp before each timed window.

Benchmark Results: No Cache → Memcached → Redis

Configuration p50 TTFB p95 TTFB Avg DB Queries/req PHP Peak Mem
No object cache (baseline) 620 ms 1,140 ms 63 48 MB
Memcached 1.6.22 + W3TC 2.7.5 280 ms 510 ms 18 46 MB
Redis 7.2 + Redis Object Cache 2.5.0 195 ms 340 ms 14 45 MB

The headline numbers: Redis brought p50 TTFB from 620 ms down to 195 ms — a 68.5% reduction. Memcached landed at 280 ms, a 54.8% reduction. Both are meaningful, but Redis outperformed Memcached by 85 ms at the median and 170 ms at the 95th percentile under this workload.

Database query count dropped from 63 per request to 14 with Redis and 18 with Memcached. That difference (4 additional queries per request with Memcached) is small in absolute terms but compounds quickly at scale — at 50 VUs over 5 minutes, it adds up to roughly 12,000 extra database round-trips.

Why Redis Pulled Ahead in This Workload

The performance gap has a few concrete explanations.

Data structure support. Redis supports native hashes, sorted sets, and lists. The Redis Object Cache plugin uses this to store WordPress cache groups as Redis hashes, which means invalidating a group (e.g., flushing all post-related cache keys when a post is updated) is a single O(1) command. Memcached has no native group invalidation — W3TC works around this with a versioning scheme that still requires multiple round-trips.

Persistence and warm-up time. Redis with AOF or RDB persistence survives a restart with its cache intact. After rebooting the server during testing, Redis re-served cached data within seconds of WordPress reconnecting. Memcached is in-memory only; every restart means a cold cache and a spike in database load until the cache warms again. On managed hosts that restart containers frequently, this is a real operational difference.

Connection overhead. Redis Object Cache 2.5.0 uses the PhpRedis extension (compiled, not pure PHP), which keeps a persistent connection per PHP-FPM worker. W3TC's Memcached integration uses the php-memcached extension in the same way, so this is roughly a wash — but Redis's pipelining support lets it batch multiple GET commands in a single TCP round-trip, reducing latency further under concurrent load.

When Memcached Is Still a Reasonable Choice

Redis wins on raw TTFB in this benchmark, but Memcached is not obsolete.

  • Memory efficiency for simple string caches. If your site does not use complex cache-group invalidation and your object cache is mostly simple key-value pairs (transients, simple option caches), Memcached uses slightly less memory per entry. On a server with 1–2 GB RAM shared with MariaDB, that margin matters.
  • Managed host availability. Several managed WordPress hosts (Kinsta, WP Engine, Cloudways) offer Redis as a premium add-on but include Memcached in base plans or make it easier to provision. If Redis costs an extra $15–30/month on your host and your site is not WooCommerce-heavy, the ROI calculation changes.
  • Horizontal scaling. Memcached was designed for distributed caching across multiple nodes. If you run a multi-server WordPress setup (multiple PHP-FPM nodes behind a load balancer), Memcached's native clustering is simpler to configure than Redis Cluster or Redis Sentinel, though Redis has caught up significantly in this area with Redis 7.x.

Recommended Configuration Settings

If you decide to move forward with Redis (the better choice for most single-server managed WP setups), these are the specific settings that affected benchmark results.

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

maxmemory 512mb
maxmemory-policy allkeys-lru
save ""
# Disable persistence for pure cache use; re-enable if you need warm restarts
tcp-keepalive 60

Setting maxmemory-policy to allkeys-lru ensures Redis evicts the least-recently-used keys when memory fills, rather than returning errors to WordPress. Disabling save removes disk-write overhead if you treat Redis purely as a cache (acceptable for most setups; re-enable RDB if you want warm restarts).

Redis Object Cache plugin (wp-config.php):

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_PREFIX', 'mysite_' ); // isolate keys if sharing Redis across sites

The WP_REDIS_TIMEOUT and WP_REDIS_READ_TIMEOUT values of 1 second are intentionally conservative. If Redis becomes unavailable, WordPress falls back to the database rather than hanging. Without these, a Redis outage can cause requests to queue and TTFB to spike past your no-cache baseline.

If you use Memcached instead (W3TC settings that matter):

  • Set "Memcached servers" to 127.0.0.1:11211
  • Enable "Verify reachability" so W3TC falls back gracefully
  • Set object cache lifetime to 3600 seconds (the W3TC default of 180 seconds is too aggressive for WooCommerce product data)
  • Disable W3TC's page cache if you have a separate full-page cache layer (Nginx FastCGI cache, or your host's built-in cache) — running both simultaneously caused cache stampedes in my testing that raised p95 TTFB by ~90 ms

Hosting Compatibility: What to Check Before Installing

Not every managed WordPress host allows you to install a custom object cache drop-in (wp-content/object-cache.php). Before configuring either backend, verify the following:

Host type Redis availability Memcached availability Custom drop-in allowed
Self-managed VPS (DigitalOcean, Linode, Hetzner) Install yourself Install yourself Yes
Cloudways Yes (add-on, ~$10/mo) Not offered Yes
Kinsta Yes (included on most plans) Not offered Yes (auto-configured)
WP Engine Yes (add-on) Not offered Restricted (use their plugin)
Shared cPanel hosts Rarely Sometimes Often blocked

If your host restricts the object-cache drop-in, a third-party Redis plugin will not work regardless of what Redis credentials you provide. In that case, the host's native caching layer is your only option — which is worth factoring into this guide on choosing a VPS with flexible infrastructure before you sign up.

Do This First

Before installing any object cache plugin, run a baseline measurement. Query Monitor (free, wordpress.org/plugins/query-monitor) will show you the database query count on any page load. If you are seeing fewer than 15 queries per request, object caching will have limited impact — your time is better spent on image optimization or reducing plugin count.

If you are seeing 40 or more queries per request on a standard page load, that is the signal to act. Install Redis Object Cache, connect it to a local Redis instance configured with allkeys-lru, and re-run your Query Monitor check. In the test environment above, that single change dropped the query count from 63 to 14 and cut p50 TTFB by 425 ms.

Measure first, then install. The query count tells you whether the investment is worth making before you spend time on server configuration.

Conclusion

WordPress object caching — specifically Redis — produced the largest single TTFB improvement in this benchmark series, outperforming Memcached by 85 ms at the median and 170 ms at the 95th percentile. The gap comes from Redis's native cache-group invalidation, pipelining support, and optional persistence across restarts.

Memcached remains a practical choice when your host includes it at no extra cost and your workload is simple key-value caching without heavy group invalidation. But for WooCommerce stores or any WordPress site with complex transient usage, Redis with the Redis Object Cache plugin and a properly tuned maxmemory configuration is the more reliable path to a lower TTFB.