Object Caching for WordPress: Redis vs Memcached vs Built-In Cache (Decision Guide)

WordPress’s object cache stores database query results and computed values in memory so they don’t need recalculating on every page load. The built-in implementation resets every request—useful but limited. Persistent object caching via Redis or Memcached keeps cached objects across requests, reducing database load significantly. Choosing between them depends on your hosting environment, site complexity, and actual performance needs.

What object caching does for WordPress

Every WordPress page load executes numerous database queries: loading options, fetching post data, checking user permissions, retrieving widgets, processing menus. Many of these queries return identical results across requests. Object caching stores these results in memory, serving them without hitting the database.

The built-in WordPress object cache (WP_Object_Cache) works within a single request. It prevents duplicate queries within the same page load—useful if a theme or plugin requests the same data multiple times. But when the request ends, the cache clears. The next request starts fresh with all queries re-executed.

Persistent object caching extends this across requests. Redis or Memcached keeps cached objects in memory between page loads. The first request after cache fills queries the database and stores results. Subsequent requests retrieve results from memory without touching the database at all. This dramatically reduces database load.

When you actually need persistent object caching

Database query time dominating page generation indicates a need. If profiling shows 200+ database queries taking 300ms+ per page, persistent object caching can reduce both query count and time significantly—often by 50-80%.

Logged-in user experience suffers without it. Page caching handles anonymous visitors well, but logged-in users (admins, members, WooCommerce customers) bypass page cache and generate dynamic pages every time. Object caching reduces the database cost of these dynamic pages.

High-traffic sites with many concurrent users benefit most. Each concurrent request generates database queries. With 20 concurrent requests each making 100 queries, the database handles 2,000 queries simultaneously. Object caching can reduce this to 200-400 queries—a dramatic load reduction.

WooCommerce sites gain significant benefit because WooCommerce generates heavy database queries for products, cart calculations, and session management. Object caching reduces repetitive query execution and improves response time for dynamic WooCommerce pages.

Redis: the feature-rich option

Redis provides persistent, in-memory data storage with rich data structures. Beyond simple key-value caching, Redis supports lists, sets, sorted sets, and hashes. For WordPress, these advanced structures aren’t typically needed, but Redis’s overall architecture provides advantages.

Redis persists data to disk, surviving server restarts. This means your cache warms up faster after hosting maintenance or reboots. Memcached loses all cached data on restart, requiring full cache rebuilding from database queries.

Redis supports data expiration granularly. Different cache groups can have different TTLs. Frequently changing data expires quickly while static data persists longer. This granularity improves both freshness and hit rates.

The overhead: Redis uses more memory per cached item than Memcached due to data structure overhead. For WordPress object caching where items are simple key-value pairs, this overhead provides features you mostly don’t use. Memory efficiency matters when your hosting allocation is limited.

Memcached: the simple, fast option

Memcached is purpose-built for distributed caching with minimal overhead. It stores key-value pairs in memory with excellent performance for the exact use case WordPress object caching requires: fast get/set operations on simple data.

Memcached uses memory more efficiently for simple caching workloads. Each cached item has less overhead than Redis. On memory-constrained hosting, this efficiency means more cached items fit in your allocation.

Multi-server distribution is Memcached’s architectural strength. For sites running on multiple application servers, Memcached distributes cache across servers natively. Redis supports clustering but requires more configuration for comparable distribution.

The limitation: Memcached doesn’t persist data. Server restarts clear the cache entirely. Cache rebuilds from database queries, which temporarily increases database load until the cache warms. For frequently restarted servers, this creates periodic performance dips.

WordPress built-in cache: when it’s enough

Small, low-traffic sites may not need persistent object caching at all. If your page generation time is already under 200ms with reasonable database query counts (under 50), the complexity of adding Redis or Memcached may not justify the improvement.

Sites with effective page caching and few logged-in users generate dynamic pages infrequently. If 95% of traffic serves from page cache and only admin users generate dynamic pages, the database handles this limited load easily without persistent object caching.

Hosting that doesn’t support Redis or Memcached makes persistent caching impossible without infrastructure changes. Many shared hosting plans don’t provide either service. Budget hosting without persistent caching can still perform acceptably for simple sites with good page caching.

Making the decision

Check your hosting first. If Redis is available and included in your plan, use it. If only Memcached is available, use that. If neither is available and your site needs persistent caching, consider upgrading hosting.

For most WordPress sites that need persistent object caching, Redis is the better default choice. Its data persistence, TTL flexibility, and broad WordPress plugin support make it the safer option. The memory overhead is rarely problematic on hosting plans that provide Redis.

Choose Memcached when memory efficiency is critical (limited allocations), your site runs on multiple application servers needing distributed caching, or your hosting specifically optimises for Memcached.

Stick with built-in caching if your site is small, low-traffic, primarily static with effective page caching, or your hosting doesn’t support persistent caching and the current performance is acceptable.

Implementation notes

WordPress persistent caching requires both the caching service (Redis/Memcached running on your server) and a WordPress drop-in plugin (object-cache.php). Popular plugins include Redis Object Cache, Object Cache Pro, and W3 Total Cache’s Memcached support.

Monitor cache hit rates after implementation. A healthy object cache shows 80%+ hit rate—most requests find cached data. Low hit rates indicate either very diverse data (hard to cache) or configuration issues (cache too small, inappropriate TTLs).

Watch memory usage. If your cache allocation fills completely, eviction policies remove older items to make room. If eviction happens frequently, increase allocation or review what’s being cached—some plugins cache excessively.

Object caching is one layer in a comprehensive performance strategy. It works best alongside page caching and appropriate hosting. Implementing object caching alone, without page caching, captures only a fraction of potential improvement.