If your WordPress site feels slow even with a good page cache in place, the bottleneck is often somewhere page caching cannot reach: the database. Every uncached page load — every logged-in visit, every cart page, every admin screen, every search — forces WordPress to run dozens or hundreds of database queries. An object cache sits between WordPress and the database and remembers the answers, so repeated queries return in milliseconds instead of hitting MySQL again. The two serious options are Redis and Memcached, and both reach WordPress through the same mechanism: an object cache drop-in.
This guide explains what a drop-in actually does, how Redis and Memcached compare in real WordPress use, which one to pick for your hosting setup, and how to verify the cache is genuinely working — because an object cache that is installed but not running is one of the most common silent failures on WordPress sites.
What an Object Cache Drop-in Actually Does
WordPress already has a built-in object cache, but by default it only lives for a single page load. Each request starts with an empty cache, runs its queries, and throws the results away. That helps within one request — the same option is not fetched twice — but it does nothing for the next visitor.
A drop-in changes that. It is a single file, object-cache.php, placed in the wp-content directory, that replaces the built-in cache with a persistent one backed by an external service. Once installed, WordPress stores query results, options, and computed objects in Redis or Memcached, and later requests read them from memory instead of the database. Nothing in your theme or plugins needs to change; the drop-in hooks in at the lowest level, so every part of WordPress benefits automatically. It is one of three cache layers worth understanding — see Page Cache vs Browser Cache vs Opcode Cache in WordPress for how they fit together, and PHP OPcache for WordPress for the opcode layer that sits underneath all of this.
That distinction matters for expectations. An object cache does not make cached pages faster — a page cache already does that. It makes uncached and dynamic pages faster: wp-admin, WooCommerce checkout flows, membership dashboards, and any page that cannot be served as static HTML. If your site is mostly anonymous traffic served from a page cache, an object cache will show modest gains. If a large share of traffic is logged in, or your database is the bottleneck, the difference can be dramatic.
Redis vs Memcached: The Honest Comparison
Both are in-memory data stores, both are fast, and both have mature WordPress drop-ins. The differences are in features, not raw speed — for typical WordPress workloads, either one will remove the database bottleneck. Choose on fit, not benchmarks.
Data structures and persistence
Memcached is deliberately simple: it stores key-value pairs in memory and nothing else. When the service restarts, the cache is empty and rebuilds itself as traffic arrives. That simplicity is a strength — there is very little to misconfigure.
Redis stores richer data structures — strings, hashes, lists, sets, sorted sets — and can persist data to disk. Persistence means a restart does not necessarily mean a cold cache, and Redis can also serve as a queue or session store if your stack grows. For WordPress alone, persistence is a nice-to-have rather than a deciding factor: a cold object cache rebuilds quickly, and a cold cache is a brief slowdown, not an outage.
Eviction and memory behaviour
Both evict old data when memory fills up, but Redis gives you more control over how. You can choose eviction policies per use case and set expiry times with more granularity. Memcached’s approach is simpler and, for a standard WordPress install, perfectly adequate. Problems usually come not from the eviction policy but from a cache that is far too small for the site — if your object cache is constantly evicting data it needs again minutes later, no policy choice will save you. Size it generously: a few hundred megabytes covers most small and medium sites.
Tooling and ecosystem
Redis has the larger ecosystem around WordPress. The Redis Object Cache plugin by Till Krüss is widely used, actively maintained, and gives you a dashboard view of hit rates, memory use, and connection status. The popular Memcached drop-ins work well but the tooling is thinner, and diagnosing a Memcached problem usually means reading logs rather than opening a dashboard. If you manage the site yourself and want visibility without extra effort, that tooling gap is a real point in Redis’s favour.
Reliability and failure modes
Both fail in the same graceful way if configured correctly: if the cache service is unreachable, WordPress falls back to querying the database directly. Your site gets slower, not broken. The dangerous failure mode is different — a stale or misconfigured cache serving outdated data. That risk exists with both, and it is usually caused by a plugin or theme storing something it should not cache, or by a cache that is never flushed after bulk changes. The fix is the same either way: flush the object cache after major content or settings changes, and investigate any plugin that misbehaves with caching enabled rather than blaming the cache engine.
Which One Should You Choose?
The decision is usually made for you by your host, and that is fine. Here is the short version:
- Your host offers Redis: use Redis. It is the most common choice on managed WordPress hosting, the tooling is better, and your host’s support team will know it well. This is the default recommendation for most sites.
- Your host offers Memcached: use Memcached without hesitation. It does the WordPress job just as well, and fighting your host’s stack to install Redis yourself is rarely worth it.
- Your host offers both: pick Redis, mainly for the diagnostics and the wider plugin support.
- Your host offers neither: do not install a cache server on shared hosting yourself.
Setting Up an Object Cache Drop-in, Step by Step
The exact steps vary by host, but the shape is the same everywhere. Managed hosts often reduce this to a toggle in the hosting panel, which handles the server side and the drop-in for you.
Step 1: Confirm the service is available
Before installing anything in WordPress, confirm the cache service itself is running. On a managed host, look for a Redis or Memcached toggle in the caching section of your panel. On a VPS, check that the service is installed and listening — for Redis, redis-cli ping should answer PONG. Installing a drop-in that points at a service that does not exist gives you a site that falls back to the database on every request and an error log full of connection failures.
Step 2: Install the drop-in
The cleanest route is a reputable plugin. For Redis, the Redis Object Cache plugin installs the drop-in, adds the connection settings, and provides a status screen — see also How to Set Up Redis Cache for WordPress for the full Redis walkthrough. For Memcached, plugins such as W3 Total Cache and LiteSpeed Cache include Memcached object-cache support, or you can place a standalone drop-in such as the one from the WordPress Memcached community and configure it manually.
If you install manually, the drop-in file goes in wp-content/object-cache.php — not in the plugins folder. WordPress loads it automatically on every request. There is no activation step, which is also why a forgotten drop-in can survive plugin cleanups and keep pointing at a dead service.
Step 3: Add the connection settings
Most setups need a few lines in wp-config.php above the “stop editing” comment:
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_PREFIX', 'mysite' );The prefix matters on shared servers: it keeps your cached keys separate from other sites using the same Redis instance. If your host provides a socket path or a password instead of a host and port, use those values — the plugin’s documentation will show the exact constants. Do not guess connection details; a wrong port is the most common reason a drop-in silently does nothing.
Step 4: Verify it is actually working
This is the step most people skip, and it is the most important one. Open the plugin’s status screen if you have one and look for a connection confirmation plus a hit rate that climbs as you browse the site. Without a plugin screen, install Query Monitor temporarily and check that database query counts on repeated page loads drop sharply after the first load — a working object cache turns many repeated queries into cache hits. If query counts stay high, work through How to Find Slow Database Queries in WordPress to find what is still hitting the database.
A quick manual check also works: load an uncached page such as a category archive twice, and compare the query count or the page generation time. The second load should be noticeably lighter. If nothing changes, the drop-in is not connected — check the service status, the connection constants, and whether another drop-in file is overriding yours.
Step 5: Flush on major changes
Flushing the object cache is safe — it only deletes cached copies, never content — but it temporarily makes the site slower while the cache rebuilds. Flush after bulk imports, migrations, and plugin updates that change stored data, and after any incident where the site shows stale content. Do not set up automatic flushing on a schedule; a healthy object cache manages its own expiry.
Common Problems and Fixes
Stale content after edits: Flush the object cache once and check whether the problem repeats. If it does, a plugin is caching something it should not — disable object caching for that plugin’s data or contact its developer. Do not solve this by disabling the cache permanently.
Admin feels slower, not faster: A misconfigured or undersized cache can add overhead without benefit. Check that the service has enough memory, that the connection is local (a remote cache server adds network latency to every query), and that no other drop-in is conflicting.
Connection errors in the log: The service is down, the credentials changed, or the server ran out of memory. WordPress keeps working by falling back to the database, so this is a performance problem, not an emergency — but fix it promptly, because a site running without its expected cache layer on a busy day will feel it.
Object cache and page cache confusion: These are separate layers that solve different problems. Page caching serves static HTML to anonymous visitors; object caching speeds up the database work behind dynamic pages. Running both is normal and recommended. If you only have one, the page cache usually delivers the bigger visible win for anonymous traffic, while the object cache delivers the bigger win for logged-in traffic and admin work.
When an Object Cache Will Not Help
An object cache is not a cure for a slow site in general. It will not fix a slow theme, oversized images, render-blocking scripts, or a server that is simply underpowered. It also will not help much if your database is already fast and your queries are few — a small blog with a handful of plugins may measure no difference at all, and that is a fine outcome. Add an object cache when database work is actually a bottleneck: high query counts on uncached pages, slow admin screens, or a database server under visible strain. Measure before and after with Query Monitor so the decision is based on numbers, not enthusiasm.
The Bottom Line
Redis and Memcached both do the WordPress object-cache job well. Redis wins on tooling, diagnostics, and flexibility; Memcached wins on simplicity and does everything WordPress asks of it. For most site owners, the right choice is whichever one the host provides, installed via a reputable drop-in, verified with real measurements, and flushed only when something actually changes. Get those basics right and the engine underneath barely matters — what matters is that the cache is running, sized sensibly, and actually being hit.
