If you have ever watched a WordPress dashboard crawl, or seen wp-admin hang for two seconds on every page load, the fix is almost always the same: a persistent object cache. WordPress stores a lot of repeated database query results in memory per request, then throws them away when the request ends. A persistent object cache keeps that data alive between requests, in RAM, so the next visitor does not re-run the same forty queries. The two engines that do this job are Redis and Memcached. Both work. The interesting question is which one fits your site, and why.

What object caching actually does in WordPress

WordPress has a built-in caching layer called WP_Object_Cache. Out of the box it is non-persistent: every wp_cache_get() and wp_cache_set() call lives and dies inside a single page load. Drop in a persistent backend and those values survive. Things like the alloptions array, transients, term and taxonomy lookups, user meta, and the results of expensive WP_Query calls stop hitting MySQL on every request.

The impact is most dramatic on three kinds of sites: WooCommerce stores (cart, session, and product-meta queries are brutal), membership and LMS sites where pages are logged-in and therefore bypass full-page caching, and large content sites with thousands of terms and options. For these, a persistent object cache often shaves 200-600ms off time to first byte and removes the database as the bottleneck. If your goal is a TTFB under ~200ms and an LCP comfortably below the 2.5s Core Web Vitals threshold, object caching is frequently the single highest-leverage change you can make for dynamic pages.

Memcached: the simple, fast key-value store

Memcached is exactly what it sounds like: a distributed memory cache. It stores string-keyed blobs in RAM and gives them back fast. That is the whole product, and that focus is its strength.

Multithreaded. Memcached uses multiple threads, so on a busy multi-core server it can handle a high volume of concurrent GET/SET operations without a single thread becoming the choke point.
Predictable memory model. It uses a slab allocator with LRU eviction. You give it a memory ceiling, and when it fills up it quietly evicts the least-recently-used items. For a cache, this "just throw away old stuff" behavior is exactly what you want.
Tiny operational footprint. There is almost nothing to misconfigure. No persistence settings, no data structures, no eviction-policy debates.

The trade-offs follow from the same minimalism. Memcached values are capped at 1MB by default, which can bite if your alloptions blob or a serialized object grows large. It has no native data structures beyond plain strings, no built-in persistence, and no replication. If the process restarts, the cache is empty and rebuilds from scratch.

Redis: the data-structure server that happens to cache well

Redis started as a cache and grew into a general-purpose in-memory data store. For WordPress it is still used primarily as an object cache, but it brings capabilities Memcached lacks.

Rich data types. Hashes, sorted sets, lists, and bitmaps mean a plugin can do more than store-and-fetch. The popular Redis Object Cache plugin leans on this.
Optional persistence. RDB snapshots and the AOF (append-only file) log let Redis survive a restart with a warm cache. For a site where rebuilding the cache causes a noticeable cold-start spike, this matters.
Configurable eviction. Policies like allkeys-lru, volatile-lru, and allkeys-lfu let you tune exactly how Redis behaves when maxmemory is reached. For a pure cache you almost always want allkeys-lru with a sensible maxmemory.
Larger values and atomic operations. No 1MB ceiling to trip over, and atomic increments make it usable for rate limiting and locks beyond plain caching.

The catch historically was concurrency: core Redis command execution is single-threaded. In practice this rarely matters for WordPress, because each request issues a small number of fast operations, and modern Redis (6+) added multithreaded network I/O. But on an extremely high-throughput single instance, that single execution thread is the theoretical ceiling Memcached does not have.

So which one is faster?

For typical WordPress workloads, the honest answer is: the difference is negligible. Both return a key from RAM in well under a millisecond. Benchmarks that show one "winning" are usually measuring synthetic throughput under artificial concurrency, not the dozen-keys-per-page-load pattern a WordPress request actually produces. If anyone tells you switching from one to the other made their pages load 30% faster, the real cause was almost certainly going from no persistent cache to any persistent cache.

The performance decision that actually matters is not Redis vs Memcached. It is whether you are using a good drop-in. The Redis Object Cache plugin by Till Krüss is the de facto standard on the Redis side and ships with a WP_REDIS_ configuration surface plus a Relay/igbinary fast path. On the Memcached side, the older memcached and wp-memcached drop-ins do the job but receive far less active maintenance.

The factor that usually decides it: your host

In real life you rarely choose freely. Your managed host has already picked for you, and fighting that choice is not worth it.

Kinsta, WP Engine, Cloudways, and most modern managed WordPress hosts ship Redis (often as a paid add-on on Kinsta and WP Engine). On these, Redis is the path of least resistance and the one their support team knows.
Some older or budget shared hosts only offer Memcached, sometimes through a one-click toggle in the control panel.
SpinupWP, GridPane, and self-managed servers let you install either; Redis is the more common default in their docs and provisioning scripts.

If your host offers Redis, use Redis. The plugin ecosystem is healthier, the persistence option is genuinely useful, and the configuration is better documented. Reach for Memcached primarily when it is what your host gives you, or when you are running a large multithreaded cache layer shared across many app servers and want Memcached's threading model.

A practical setup checklist

Confirm the server has the engine and the matching PHP extension. For Redis you need the phpredis extension (not just Predis); for Memcached you need the memcached PHP extension (note: memcache without the d is the older, weaker one).
Install the drop-in. For Redis, install and enable the Redis Object Cache plugin, then click "Enable Object Cache." It writes object-cache.php into wp-content/.
Set a memory ceiling and eviction policy so a runaway cache cannot OOM the box. For Redis: maxmemory 256mb and maxmemory-policy allkeys-lru is a sane starting point for a single site.
Use a unique key prefix (WP_REDIS_PREFIX) if multiple sites share one instance, so they do not collide or flush each other.
Verify it is working. The Redis plugin shows a connected status and live hit/miss stats. A healthy site runs an 85-95%+ hit ratio. A persistently low ratio means something is flushing the cache constantly, usually an aggressive plugin.

The bottom line

Redis and Memcached are both excellent persistent object caches for WordPress, and either will transform a database-bound dynamic site. Memcached is the leaner, multithreaded, do-one-thing-well option. Redis is the richer, more flexible, better-supported one with optional persistence — and it has won the WordPress ecosystem by a wide margin. For a new site where you get to choose, pick Redis with the Redis Object Cache plugin. For an existing site, the more important question is not which engine you run but whether you have any persistent object cache running at all — because going from none to either is where nearly all the speed actually comes from.

Object Caching: Redis vs Memcached for WordPress