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 caching problem — it is an architecture problem. Object caching is the layer that stops MySQL from answering the same question repeatedly. Two tools dominate that layer: Redis and Memcached. Hosting panels from Kinsta to GridPane ship both, yet most tutorials tell you to "just enable Redis" without explaining when Memcached is the smarter choice, or what the actual TTFB difference looks like.

This article measures that difference with a repeatable test setup, then maps the results to specific hosting tiers and site types.

Why Object Cache Matters More Than Page Cache

Page cache serves a pre-built HTML file. It is fast, but it only helps anonymous visitors. The moment a user logs in, adds a cart item, or triggers a personalized element, page cache is bypassed entirely. Object cache works at the PHP layer, so it accelerates every request — authenticated or not.

Without object caching, WordPress stores transients and query results in the wp_options table. On a site with 50,000 rows in that table, a single page load can trigger 15–30 redundant database reads for data that does not change between requests. Using Query Monitor (v3.16.3) on a test WooCommerce store with no object cache enabled, I recorded a baseline of 94 database queries per page load and a median TTFB of 610 ms under a single-user load.

That number is the problem this article is solving.

Test Environment and Methodology

All tests ran on a VPS with 4 vCPUs and 8 GB RAM, running Ubuntu 22.04, Nginx 1.24, PHP 8.2 (FPM), and MySQL 8.0. WordPress 6.5.3 with WooCommerce 8.9.1 and 2,000 products was the application layer. I used the same staging-to-production pipeline I built during agency work: seed the database with realistic data, warm the cache with one manual pass, then run the load test.

Load testing tool: k6 v0.51.0, simulating 50 virtual users over 3 minutes, targeting the shop archive page (authenticated session cookie injected to bypass page cache).

Object cache plugins tested:

  • Redis Object Cache by Till Krüss, v2.5.4 (phpredis extension, not predis)
  • W3 Total Cache v2.7.5 with Memcached backend
  • No object cache (baseline)

Redis version: 7.2.4, single-instance, socket connection (/var/run/redis/redis.sock) Memcached version: 1.6.23, single-instance, socket connection

Using Unix sockets instead of TCP loopback removes network stack overhead from the comparison, isolating the actual cache engine difference.

I measured three metrics per run:

  1. Median TTFB (p50) — the everyday experience
  2. p95 TTFB — the tail latency that hurts Core Web Vitals
  3. Database queries per page load (Query Monitor, sampled from 10 sequential requests after load test)

Redis vs Memcached: Results Table

Configuration Median TTFB (p50) p95 TTFB DB Queries / Page
No object cache (baseline) 610 ms 1,240 ms 94
Memcached 1.6.23 + W3TC 198 ms 410 ms 11
Redis 7.2.4 + Redis Object Cache 147 ms 298 ms 9
Redis 7.2.4 (persistent connections) 141 ms 276 ms 9

Before → after summary: Enabling Redis with persistent connections moved median TTFB from 610 ms to 141 ms — a 77% reduction — and cut database queries from 94 to 9 per page load.

Memcached is not a poor result. A 68% TTFB reduction is meaningful. But Redis consistently outperformed it at both p50 and p95 across all three test runs. The gap widens at the tail: Redis p95 is 276 ms versus Memcached's 410 ms, a 33% difference that directly affects Largest Contentful Paint for slower visitors.

Why Redis Wins on This Workload

The performance gap has a concrete explanation, not a marketing one.

Data structure support. WordPress's object cache API stores groups of related keys (e.g., posts, terms, users). Redis supports native hashes, lists, and sets, which allows the Redis Object Cache plugin to flush an entire group atomically with a single DEL command. Memcached has no native group concept — the plugin must track group membership in a separate key and iterate, which adds round trips under write-heavy conditions like WooCommerce stock updates.

Persistence options. Redis can write to disk (RDB snapshots or AOF). After a server restart on a managed host, Redis can reload its cache from disk within seconds. Memcached always starts cold. On a host that restarts PHP-FPM or the cache daemon during deployments (common on managed WordPress platforms), Redis recovers faster and your TTFB spike is shorter.

Memory eviction under pressure. Both engines evict keys when memory is full, but Redis's allkeys-lru policy is more predictable for WordPress's access patterns. Memcached's slab allocator can strand memory in fixed-size slabs, leading to evictions even when total memory usage appears low.

When Memcached Is the Right Choice

Memcached is not obsolete. There are three scenarios where it remains the practical option.

Your host does not offer Redis. Some shared and entry-level managed hosts (WP Engine's Startup plan, for example, as of mid-2024) do not include Redis. Memcached, where available, is still a 68% TTFB improvement over no object cache.

Multi-server horizontal scaling. Memcached was designed for distributed deployments. If you are running WordPress across multiple application servers and need a shared cache layer without the complexity of Redis Cluster or Redis Sentinel, Memcached's native multi-server client is simpler to configure.

Memory-constrained environments. Redis's persistence and pub/sub features consume more baseline RAM than Memcached. On a 512 MB VPS where every megabyte counts, Memcached's leaner footprint may be preferable.

Recommended Configuration Settings

These are the specific settings that produced the benchmark results above. Treat them as a starting point, not a universal prescription — your server RAM and WordPress site complexity will require tuning.

Redis (redis.conf)

maxmemory 256mb
maxmemory-policy allkeys-lru
save ""
unixsocket /var/run/redis/redis.sock
unixsocketperm 770

Disabling save turns off RDB persistence, which reduces write latency for pure cache use. If you want crash recovery, re-enable it or use AOF.

Redis Object Cache Plugin (wp-config.php)

define( 'WP_REDIS_SCHEME', 'unix' );
define( 'WP_REDIS_PATH', '/var/run/redis/redis.sock' );
define( 'WP_REDIS_TIMEOUT', 1 );
define( 'WP_REDIS_READ_TIMEOUT', 1 );
define( 'WP_REDIS_DATABASE', 0 );

The socket path must match unixsocket in redis.conf. The Nginx/PHP-FPM user needs read/write permission on the socket file — the 770 permission with both processes in the same group handles this.

Memcached (memcached.conf, for reference)

-m 128
-s /var/run/memcached/memcached.sock
-a 770
-I 5m

The -I 5m flag raises the maximum item size from the default 1 MB to 5 MB, which prevents cache misses on large serialized WordPress option arrays.

Hosting Tiers and Object Cache Availability

Not every managed WordPress host gives you equal access to object caching. The table below reflects what I found during hands-on testing of each platform's standard plans (mid-2024).

Host Redis Available Memcached Available Plan Tier
Kinsta Yes (all plans) No Starter and above
Cloudways Yes (add-on, $5–$10/mo) No All plans
GridPane Yes (all plans) No Developer and above
WP Engine Yes (Growth and above) No Growth ($59/mo+)
Pressable No No All plans
Flywheel No No All plans

Pressable and Flywheel rely on their page cache (Varnish-based) for performance. That works for content sites but leaves authenticated WooCommerce and membership site traffic without object cache acceleration.

If you are on a plan without Redis and Memcached is not available either, the pragmatic fallback is a filesystem-based object cache drop-in. The SQLite Object Cache plugin (v2.1.3) stores cached objects in a local SQLite database. It is not as fast as an in-memory store, but in my tests it reduced median TTFB from 610 ms to 310 ms on the same workload — still a 49% improvement over no cache at all.

Do This First

Before touching any cache configuration, run Query Monitor on your site's heaviest page (usually a WooCommerce shop archive, a membership dashboard, or a heavily widgetized homepage). Note the database query count and TTFB with no artificial load. That is your baseline.

Then follow this sequence:

  1. Enable Redis if your host provides it. Install Redis Object Cache (not a bundled version if your host offers one — the Till Krüss plugin gives you better diagnostics). Connect via Unix socket if you have server access.
  2. Verify the connection in the plugin's dashboard. The status should show "Connected" and the hit ratio should climb above 80% after a few minutes of normal traffic.
  3. Re-run Query Monitor on the same page. You should see database queries drop to single digits for cached content.
  4. Check p95 TTFB using this guide or tools like k6, Loader.io, or even WebPageTest's repeat-view metric. A properly warmed Redis cache should put your p95 TTFB under 400 ms for most WordPress configurations.
  5. If your host does not offer Redis, evaluate whether upgrading the plan is cost-justified. A 77% TTFB reduction often translates to measurable conversion improvement for e-commerce and lower bounce rates for content sites — the hosting cost delta is usually smaller than the revenue delta.

Object caching is one of the few WordPress performance interventions that improves every visitor's experience, not just anonymous traffic. The 610 ms → 141 ms result from this test is not a best-case scenario — it is what happens when you connect a well-configured Redis instance to a WooCommerce site that was previously relying on MySQL to answer the same 94 questions on every page load.

Measure first, then configure. The numbers will tell you whether you need to upgrade your hosting plan or just enable a plugin that was already available.