A WooCommerce store can be quick for anonymous visitors yet slow when customers log in or change their carts. Object caching is one possible part of that difference, alongside database queries, PHP workers and plugin behavior. This guide compares Redis and Memcached for WordPress and WooCommerce, then explains how expiration, invalidation and memory eviction affect performance and correctness. The aim is to choose a supported backend and tune it from measurements, rather than assume that a particular cache or short TTL fixes every slow page. Examples below describe possible configurations, not measured results from a customer deployment.
WordPress and WooCommerce repeatedly fetch settings, product information and other reusable data. A persistent object cache can reduce those database calls between requests. It is separate from full-page HTML caching, and it is not the authoritative store for orders or customer sessions. Both Redis and Memcached require an appropriate WordPress drop-in and a plan for cache misses, invalidation and service failures. A higher hit ratio is useful only when the returned data still belongs to the correct user and reflects the changes the application requires.
What a Persistent Object Cache Does
In WordPress, persistent object cache means that cached objects can live beyond a single HTTP request. It does not mean that they are saved to disk forever or guaranteed to survive a service restart. A Redis or Memcached drop-in can reuse objects across page loads instead of asking MySQL for the same values again. Actual gains depend on the workload, network overhead and how effectively the application uses the cache. A cold or unavailable cache also needs to be handled correctly.
WordPress repeatedly requests options, user metadata, terms and product data. Reusing suitable cached results can reduce repeated database work, but stock, tax, shipping and other changing results still need the correct context and invalidation. How often a value changes is one selection criterion; correctness and the cost of rebuilding it also matter.
OPcache stores compiled PHP bytecode; an object cache stores reusable application data. They address different work and may both help a WordPress installation. For the broader relationship between PHP-FPM, OPcache, Redis and database tuning, see the server-side WordPress optimization guide. Here, the focus is choosing and operating the object-cache backend.
Redis and Memcached Capabilities
Redis and Memcached can both serve the WordPress object-cache role, but their configuration and failure behavior differ. Memcached concentrates on in-memory key/value storage and uses multiple worker threads. Redis adds data structures, configurable eviction policies and optional persistence and replication. A WordPress drop-in may only use a subset of these capabilities, so choose based on its supported features and the operational requirements of the store.
Memcached is commonly used as an ephemeral cache for values such as serialized WordPress data. A normal cold restart can leave that cache empty, and the application must be able to rebuild missing entries from authoritative data. It is a practical choice when the existing stack supports it well and the team wants a focused cache service. Do not assume that a missing cache entry and an unreachable cache server produce the same behavior: connection failures depend on the client and drop-in implementation.
Redis offers richer data structures, optional persistence, replication and several eviction policies. Command execution is largely serialized, while background work and I/O threading vary by version and configuration. For WordPress object caching, useful controls include memory limits and policies such as approximate LRU or LFU. Those policies can retain frequently reused catalog data under pressure, but no policy guarantees a particular hit ratio or response time. Measure the store’s access pattern before choosing.
The decision starts with a maintained drop-in, compatible PHP client and an accessible cache service. Memcached may fit a simple in-memory deployment; Redis may fit a team that needs more eviction and replication controls. Neither backend automatically improves every page. Compare query counts, response times, memory use and correctness under the same workload, including a product update and an empty-cache condition.
Choose TTLs and Invalidation Rules
Define Acceptable Staleness
Consider a store that imports new prices and stock overnight. If a custom cached query is not invalidated by that import, visitors may continue to receive yesterday’s result until it expires. This is a possible failure scenario, not a measured customer incident. Choose expiration based on how much staleness the particular result can tolerate, and invalidate results when their underlying data changes. Shortening TTL can limit some stale results but does not replace correct update handling.
Separate reusable catalog results, site configuration, personalized output and authoritative session data. A custom catalog query may tolerate a short reuse period with invalidation on product changes. Core options and WooCommerce data already have cache lifecycles that should not be overridden blindly. Personalized results require the correct customer, language, currency, tax and other relevant context in their keys. Cart or session records must remain under WooCommerce’s supported storage and update behavior; they are not disposable fragments to protect by setting a one-minute TTL.
How Transients Use the Object Cache
WordPress transients express an upper expiration time for cached values. With an external object cache, they can be stored through that backend; otherwise WordPress uses the database. They may disappear before the chosen expiration, so the application must regenerate a missing value. For a costly product filter result, a few minutes may be a useful experiment if product updates also invalidate it. Expiration alone does not make cached stock or prices authoritative, and a transient must not become the only copy of business data.
Cache Groups and Drop-in Support
WordPress core uses cache groups for data such as options, user metadata and terms; WooCommerce adds its own data access and invalidation behavior. A group name does not itself provide a configurable TTL or a Redis eviction priority. Some groups are intentionally non-persistent, and support for flushing a group varies by drop-in. Preserve the existing lifecycles unless a documented customization is needed. For custom results, determine which writes invalidate them and how the result is reconstructed after a miss.
Invalidate Cached Results on Updates
Use WordPress and WooCommerce data APIs so that their normal cache invalidation runs when records change. A generic cache backend does not understand every custom product query or raw database update. When adding a transient or other custom cached result, connect invalidation to all events that change that result, including imports and relevant settings. Validate that the hooks actually fire in the store’s update paths. Correct invalidation allows useful reuse without relying on an arbitrary universal TTL.
Choosing an Initial TTL
For an illustrative custom catalog result that is safe to reuse and invalidates on updates, five to fifteen minutes can be a starting experiment. This is not a global WordPress setting or a recommendation for cart/session data. Set a tolerance for staleness, measure reuse and rebuild cost, then adjust that one result. Do not lengthen core option TTLs or shorten user groups just to follow a table. During a sale, unnecessarily short expirations can increase database pressure precisely when capacity is scarce.
Configure Memory Limits and Eviction
Eviction Under Memory Pressure
When cache memory fills, eviction determines which eligible entries can be removed before their TTL expires. Traffic spikes can increase memory pressure and cache misses. Choose a policy that fits the access pattern and confirm that every evictable value can be reconstructed from authoritative data.
Redis Eviction Policies for Cache-Only Workloads
For a Redis instance containing only reconstructable cache data, allkeys-lfu favors frequently accessed keys and allkeys-lru favors recently accessed keys, using approximate algorithms. Neither policy recognizes WordPress groups as intrinsically important. Volatile policies consider only keys with expiration, and writes may fail if too little eligible data remains to reclaim memory. Choose from actual access patterns and monitor misses and evictions; do not apply an allkeys policy to the only copy of session or queue data.
Set maxmemory with headroom for Redis overhead, the operating system and other services; a host or container limit is not the same as Redis’s memory setting. Check the configured policy and available capacity together. The official documentation explains Redis eviction policies and their selection criteria.
Memcached Item Sizes and Slab Management
Memcached uses slab classes and LRU-based mechanisms to manage stored items. Values above its configured item-size limit are rejected; automatic chunking, if any, is a client-specific behavior and must not be assumed. Check storage failures and typical serialized value sizes before raising -I. The -m option controls item-storage memory, not a strict cap on total process memory. LRU and slab-maintenance options depend on the installed version. See the Memcached server configuration notes and confirm local defaults before changing them.
Plan for an Empty Cache
An empty object cache may temporarily increase database work after a restart. A gradual, rate-limited warm-up can help, using safe anonymous requests to representative public pages or targeted application queries. A page served entirely from an HTML cache may not warm its object-cache path. Exclude cart, checkout, account and any state-changing endpoints, and avoid replaying customer sessions. Measure whether a warm-up actually reduces the workload that matters rather than adding a second burst of traffic.
Persistence, Restarts and High Availability
Cross-Request Reuse and Restart Recovery
WordPress persistence refers to reuse across requests, not guaranteed restart recovery. Memcached is normally treated as an ephemeral cache; Redis can optionally save RDB snapshots or AOF logs. For a Redis instance holding only reconstructable object-cache data, disabling persistence may be appropriate, provided the database can handle a cold rebuild. For sessions, queues or other state, decide durability separately. Do not disable persistence on a shared instance without first identifying every workload stored there.
Cache Availability and Client Failure Handling
High availability depends on more than whether cached data can be rebuilt. An unreachable cache server may trigger connection errors or delays, depending on the WordPress drop-in. Redis replicas and Sentinel can provide failover when the client supports them, but asynchronous replication can lose recent updates and requires careful invalidation behavior. A Memcached node pool also needs compatible client hashing and failure handling. Test cache outages, recovery and stale-data behavior in staging before relying on either arrangement for a store.
Separate Workloads with Different Requirements
Object cache, sessions and queues often need different durability and eviction rules. Separate Redis instances can give them independent memory limits and policies. Selecting different logical databases within one Redis instance only separates key namespaces; they still share process resources and the instance’s eviction configuration. Logical databases do not provide a per-application memory boundary. Design the separation so a queue surge cannot consume the capacity assumed by the object-cache service.
Example Configuration and Validation
Redis Settings for a Dedicated Cache Instance
The following is an illustrative excerpt for a dedicated, reconstructable object-cache instance. The 2 GB value is an example allocation, not a recommendation to give Redis half of every server. Confirm available memory, other services, connection security and the cost of rebuilding an empty cache before applying it. Inline explanatory comments are placed on separate lines so they cannot be parsed as extra directive arguments.
# redis.conf excerpt: cache-only instance
maxmemory 2gb
maxmemory-policy allkeys-lfu
# Disable AOF only for reconstructable cache data.
appendonly no
# Disable RDB snapshotting only for this cache-only instance.
save ""
latency-monitor-threshold 100
Leave headroom for Redis overhead, replication or persistence buffers where used, the operating system and other services. A container limit is not the same as maxmemory. Monitor used_memory, RSS, evicted_keys, hits and misses through INFO; use latency-monitor or application metrics for latency. Rising evictions can indicate capacity pressure, but the response should depend on reuse and workload. Large serialized values, expensive commands and rebuilding too many keys at once may need application changes rather than a longer TTL.
Memcached Configuration Flags
This foreground example is for an unprivileged service account on a host where the application connects locally. It binds TCP to loopback, disables UDP explicitly, allocates an illustrative 2 GB for items and permits items up to 2 MB. Size these values for the workload and check memcached -h for the installed version. A packaged system service usually expresses the same settings in its service configuration.
memcached -l 127.0.0.1 -p 11211 -U 0 -m 2048 -I 2m -t 4
The -t flag sets worker threads; more threads do not guarantee faster responses. Modern versions already enable several maintenance behaviors that older examples list explicitly. Monitor get_hits, get_misses, evictions, storage errors and slab behavior through the Memcached protocol. Large, rarely reused values can consume capacity without useful hits, so increasing the item-size limit is not always the answer. Keep the service on trusted interfaces and budget for process overhead beyond the -m allocation.
WordPress Drop-in Configuration
A working setup needs a maintained object-cache.php drop-in, the required PHP client and an accessible backend. The Redis snippet below uses the Redis Object Cache plugin’s documented constants; they are not universal WordPress settings. Memcached drop-ins have different connection and prefix formats, so use the selected implementation’s documentation instead of copying a generic $memcached_servers array. Enabling WP_CACHE alone does not establish either backend.
// wp-config.php: Redis Object Cache plugin example
// Install and enable its object-cache.php drop-in separately.
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_PREFIX', 'store_prod_');
// WP_REDIS_MAXTTL is a plugin-wide upper limit, not a cart/catalog policy.
// Memcached: use your chosen drop-in's documented server and prefix settings.
The Redis plugin documents WP_REDIS_PREFIX as the replacement for WP_CACHE_KEY_SALT. Prefixes help prevent key collisions; they do not provide access isolation or protection from a broad flush. Group-specific expiration and ignored-group settings depend on the drop-in. Keep core and WooCommerce lifecycles intact, and confirm wp_cache_supports('flush_group') before using group-flush functionality. Do not infer that an options or sessions group should have a particular TTL merely from its name.
Measure Cache and Application Behavior
Track hit ratio, evictions, cache connection errors and application response-time percentiles alongside database query work. redis-cli INFO provides Redis server statistics; Memcached exposes stats through its protocol, not a shell command named memcached stats. Compare counter deltas over consistent intervals, since cumulative totals include earlier workloads. Use drop-in or APM data for WordPress group-level behavior. Verify price updates, coupons and separate customer sessions as functional checks alongside those performance measurements.
Deployment and Cache Invalidation
If a deployment changes serialized values or key structure, prefer versioned application keys or targeted invalidation supported by the drop-in. A broad cache flush can affect other sites sharing the service and can create a database spike; it is not automatically gentle. If warm-up is useful, make rate-limited anonymous requests to safe public catalog paths that actually execute the application. Exclude checkout, cart, account and state-changing requests, and plan how the old and new application versions coexist during deployment.
When to Choose Redis, When to Choose Memcached
Consider two hypothetical stores. A modest catalog with a well-supported Memcached drop-in may benefit from the team’s existing experience operating a simple in-memory service. A larger catalog with a strongly skewed access pattern may justify evaluating Redis LFU against LRU under representative traffic. These are selection scenarios, not customer case studies or promised results. In either store, verify updates and cache outages before concluding that the chosen backend is a good fit.
Memcached can be appropriate when a focused cache service and the available drop-in meet the requirements. Redis adds controls for eviction and optional replication and persistence, but those controls bring decisions about topology and failure behavior. Compatibility, measured reuse, available memory and the team’s operating knowledge matter more than a universal speed ranking. The wrong integration can cause errors with either backend even if the underlying cache service is fast.
Common Cache Configuration Mistakes
Incorrect Context or Invalidation for Personalized Data
A personalized free-shipping message can become stale when the cart, address or promotion changes. A short TTL only shortens some stale periods; it does not correct a missing customer context or invalidation event. Include the relevant context in custom keys and invalidate on changes, or keep the fragment out of shared caching. Confirm behavior with at least two independent customer sessions.
Volatile Policies with Non-Expiring Keys
Redis volatile policies only consider keys with expiration. If non-expiring keys consume the available memory and eligible keys cannot free enough space, write operations can fail. Monitor memory and application errors rather than assuming the policy protects important data. An allkeys policy is an option for reconstructable cache-only workloads; move authoritative sessions or queues to an appropriate separate service instead of making them eligible for arbitrary eviction.
Values Above the Memcached Item-Size Limit
A serialized value above the configured Memcached item-size limit can fail to store. Inspect storage failures and value sizes before changing -I. Reducing an unnecessarily large cached result may use memory more effectively than increasing the limit for every slab profile. Treat cache misses as normal and ensure the application can compute the result without silently relying on a successful write.
Mixing Workloads in One Redis Instance
Keep workloads with different durability and eviction requirements in separate Redis instances where needed. Logical database numbers and key prefixes are useful namespacing tools, but neither creates an independent memory quota or makes session data safe from instance-wide eviction. Inventory the workloads before changing persistence or performing a service-wide flush.
Other Application Bottlenecks
A low cache hit ratio is not the only possible bottleneck. Exhausted PHP workers, database contention, slow external requests and overly large application objects can limit gains. Compare the same workload before and after one change, and consult the linked server-side tuning guide for related layers. Do not use a performance improvement to overlook incorrect prices, stale updates or cross-customer output.
Official Documentation
Consult the WordPress object-cache reference, Redis eviction documentation and Memcached configuration notes. Check those references against the installed versions and the selected WordPress drop-in before changing settings.
Selection and Validation Checklist
A persistent object cache can reduce repeated database work when the application uses it correctly. Redis offers configurable eviction and optional durability and replication; Memcached offers a focused in-memory backend. Start with a maintained, compatible drop-in and an understanding of which data can be reconstructed. Then measure response times, database load, misses and errors under representative store activity rather than choosing from generic speed claims.
For custom cached results, choose TTL from acceptable staleness and invalidation behavior. Keep cart, checkout and account HTML out of shared full-page caching, and preserve WooCommerce’s session and update logic. On a dedicated Redis cache instance, evaluate an allkeys policy with memory headroom; disable persistence only when every stored value is reconstructable. On Memcached, size item storage and item limits from observed data and restrict network access. Finally, validate cold starts, outages and recovery without replaying customer checkout actions.
Before rollout, record the selected backend, drop-in version, memory allocation and rollback procedure. Run the same product-update, coupon and customer-isolation checks after deployment. An improvement is useful only when the store remains correct as well as responsive.
