Object caching in WordPress stores the results of expensive database queries in memory so PHP does not have to ask MySQL the same question thousands of times per hour. For high-traffic sites, the two serious backends are Redis and Memcached, and both will cut database load dramatically once configured properly. The honest answer in 2026: Redis wins for most WordPress workloads, but Memcached still makes sense in specific setups, and how you tune either one matters more than which logo you pick.
What Object Caching Actually Does in WordPress
Every WordPress page load fires dozens to hundreds of queries: options, post meta, term relationships, user meta, transients. By default WordPress caches those results in PHP memory for the duration of a single request, then throws them away. A persistent object cache keeps them in a shared memory store so the next visitor, and the next request from the same visitor, reuse the work.
The mechanism is simple. A drop-in file at wp-content/object-cache.php replaces the default WP_Object_Cache class with one that talks to Redis or Memcached over a socket or TCP. WordPress code does not change, which is why almost any plugin benefits automatically.
On the sites we watch, a warm object cache typically removes 60 to 90 percent of queries per request. That usually shows up as 150 to 400 ms shaved off time to first byte on dynamic, uncacheable pages.
Why This Is Different From Page Caching
Page caching serves a finished HTML file and skips PHP entirely, which is why it looks faster in benchmarks. It also does nothing for the traffic that actually hurts you: logged-in users, cart and checkout pages, search results, wp-admin, and REST or GraphQL requests. Object caching is what keeps those paths alive.
- Page cache helps anonymous visitors on repeat URLs, handled well by LiteSpeed Cache at the server level.
- Object cache helps every request, including the ones page caching must bypass.
- Both together is the normal configuration for a busy store, membership site or magazine, not an either/or decision.
Overview of Redis for WordPress
Redis is an in-memory data structure server. It handles strings, hashes, lists, sorted sets and more, and it can persist data to disk with RDB snapshots or an append-only file. That persistence is the practical difference for WordPress: restart the service and your cache can come back warm instead of empty.
Redis is single-threaded for command execution (with I/O threading available in modern builds), yet it still pushes well past 100,000 operations per second on a modest VPS core. It supports LRU and LFU eviction, TTL per key, atomic increments, pub/sub and Lua scripting, which is why the more advanced drop-ins can do things like key groups and cache flush by prefix.
For WordPress specifically, the ecosystem has consolidated around Redis. The Redis Object Cache plugin by Till Kruess is the most widely installed free option, WP Redis is a solid alternative, and Object Cache Pro is the commercial choice used by many managed hosts.
Overview of Memcached for WordPress
Memcached is deliberately narrower: a distributed, multi-threaded key-value store with a slab allocator and a strict LRU. It does one job, does it with very little overhead, and scales across CPU cores better than a single Redis instance because reads and writes are threaded. The official Memcached overview is refreshingly blunt about that scope.
Where Memcached shines is a huge, flat cache of small values with predictable memory use. Its client-side hashing spreads keys across a pool of nodes with no cluster coordination, which some large multisite networks still prefer. The trade-off: no persistence, no data structures, and a flush wipes everything for every site sharing the instance.
Related reading: Edge Caching vs. Traditional CDNs: What WordPress Users Need to Know.
Related reading: How to Debug High CPU Usage on Your WordPress Server.
We cover this topic in more depth in How to Stress Test Your WordPress Hosting Before a Major Traffic Spike.
Setting up Memcached with WordPress means installing the PHP memcached extension (the newer libmemcached-based one, not memcache) plus a drop-in. Support is thinner than it was five years ago, and that alone pushes most new builds toward Redis.
Redis vs. Memcached: The Differences That Matter
- Persistence: Redis can survive a restart with AOF or snapshots. Memcached always starts cold, so expect a brief spike in database load after any restart or deploy.
- Threading: Memcached is multi-threaded; a single Redis process uses one core for commands. On a 32-core cache node with extreme throughput, Memcached can be more efficient per box.
- Data types: Redis hashes let a drop-in group keys and invalidate selectively. Memcached stores opaque strings only.
- Eviction control: Redis offers allkeys-lru, allkeys-lfu, volatile variants and noeviction. Memcached gives you LRU per slab class, which can waste memory when value sizes vary.
- Value size: Memcached defaults to a 1 MB item limit, and WordPress serialized option arrays on big sites can exceed it. Redis handles multi-megabyte values without special flags.
- Tooling: Redis has INFO, SLOWLOG, MONITOR and mature dashboards. Memcached stats are basic by comparison.
- Cost: Both are open source and free. Managed cloud instances tend to run 10 to 40 dollars per month for the 1 to 4 GB tiers you would actually need, and Redis pricing is usually a few dollars higher for the same memory.
If your workload is WooCommerce, LMS, forum or membership traffic, the persistence and richer eviction control usually decide it. That is why our WooCommerce hosting stack ships Redis by default.
The Part Most Comparisons Skip: Tuning and Failure Modes
Installing a plugin is ten minutes of work. Keeping the cache healthy under real traffic is the part that separates a 40 percent improvement from a 5 percent one, and most published comparisons never get there.
Size Memory for Your Actual Key Set
A single busy WordPress site typically holds 150 MB to 800 MB of object cache data once warm; large WooCommerce catalogs can pass 2 GB. Set maxmemory above your steady-state working set plus roughly 30 percent headroom, and choose allkeys-lru so Redis evicts instead of erroring. Undersized memory produces constant eviction, and a cache that thrashes is slower than no cache.
Watch the Hit Ratio, Not the Uptime
A healthy WordPress object cache runs a 95 percent or better hit ratio. Below 90 percent, something is wrong: too-short TTLs, autoloaded options bloat, a plugin calling wp_cache_flush() on every save, or a cron job rewriting transients. Pair Redis metrics with request-level data from your hosting analytics so you can tie a ratio drop to a specific deploy.
Isolate Keys Per Site
Always set a unique WP_CACHE_KEY_SALT per install, and use separate Redis databases or instances for staging and production. Shared prefixes are how a staging flush ends up clearing production, which I have seen take a store’s database from 20 percent CPU to saturated in under a minute.
Plan for the Stampede
When a hot key expires under heavy load, hundreds of PHP workers may rebuild it at once. Redis handles this better because a good drop-in can use locks or probabilistic early expiry; Memcached leaves it to your code. On a site doing 500,000 monthly visits, that difference is the gap between a traffic spike being boring and being an incident on your status page.
Prefer Unix Sockets When You Can
If Redis runs on the same machine, a Unix socket removes TCP overhead and typically saves 0.1 to 0.3 ms per operation. Multiply by 300 cache calls per request and it is measurable. Across servers, keep the cache node in the same region and availability zone, since latency between the app and cache is charged on every single lookup.
How to Choose in 2026
- Choose Redis for WooCommerce, membership, LMS and news sites, anything with heavy logged-in traffic, and any setup where a warm cache after restart matters.
- Choose Memcached if you already run a multi-node Memcached pool, your values are uniformly small, and you need multi-threaded throughput on one box.
- Choose neither yet if your site serves under about 10,000 monthly visits and has no logged-in area. Fix PHP version, queries and page caching first.
- Run both only if a legacy application demands Memcached; two memory stores on one server is usually wasted RAM.
Redis also pairs better with modern architectures, whether you are running a decoupled front end (see our take on headless versus traditional WordPress) or optimizing structured responses for AI answer engines, where REST endpoints get hit constantly and never touch a page cache.
Frequently Asked Questions
Is Redis faster than Memcached for WordPress?
In real WordPress workloads the difference is usually under 5 percent, well inside normal variance. Redis feels faster in practice because it survives restarts warm, avoids the 1 MB item limit on large option arrays, and supports smarter invalidation through its drop-ins.
How much memory should I allocate to a WordPress object cache?
Start at 512 MB for a single busy site and 2 to 4 GB for a large store or multisite network. Check used_memory and evicted_keys after a week of normal traffic, then raise the limit if evictions are climbing steadily.
Which persistent object cache plugin should I install?
The free Redis Object Cache plugin covers most sites and includes a diagnostics screen with hit ratio and latency. W3 Total Cache and WP Redis also work, while Object Cache Pro (around 95 dollars per year) adds compression, better serialization and per-group flushing for large stores.
Does object caching help WooCommerce checkout and cart pages?
Yes, and it is one of the few things that does, because cart, checkout and account pages must bypass page caching entirely. Sites moving from no object cache to a tuned Redis instance commonly see admin and checkout response times drop 30 to 50 percent.
Can I run Redis on cheap shared hosting?
Rarely, since most low-cost shared plans block the PHP Redis extension or give no dedicated memory for it. Look for a plan that lists Redis or Memcached explicitly, which is why our affordable WordPress hosting tiers include object caching rather than treating it as an upsell.
Will object caching break my site if the cache goes down?
A well-written drop-in fails gracefully and falls back to direct database queries, so pages still load. The risk is load, not breakage: expect a temporary 3x to 10x jump in database queries until the cache warms again.
Want Redis Configured Properly, Not Just Installed?
We set up Redis object caching, memory limits and eviction policy per site, then monitor hit ratio so problems surface before your visitors feel them. Talk to our team about your traffic profile, or look at how we handle memory-hungry builds on WordPress course hosting plans.
[…] Related reading: Object Caching in WordPress: Redis vs. Memcached for High-Traffic Sites. […]
[…] the two as complementary layers rather than alternatives. If you want the detail, our breakdown of Redis vs. Memcached for high-traffic WordPress sites covers how to size the memory pool and what hit rates to […]
[…] repeat reads into a persistent object cache, which is why Redis or Memcached often cuts database load 60 to 80% on logged-in […]