Redis Object Cache for WooCommerce: What It Speeds Up (and What It Doesn't)

Redis object caching is one of the most-recommended and least-well-explained WooCommerce performance improvements. Most guides say “install Redis” and leave it at that. This guide covers what Redis actually accelerates, what it doesn’t, the WooCommerce-specific edge cases, and how to configure it so you get the advertised performance rather than the default mediocre results.

It applies to any WooCommerce store on managed hosting where Redis is available at the server level, or any self-managed server where you can install and configure Redis directly.

What object caching actually is

WordPress has an internal object cache — a PHP array that stores the results of database queries for the duration of a single page request. Without a persistent object cache, that array is built up during the request and thrown away at the end. The next request starts fresh and re-runs every query.

A persistent object cache (Redis or Memcached) changes that. When WordPress executes a database query, the result is stored in Redis with a cache key derived from the query. The next request — even from a different user, on a different page — can read that cached result without hitting the database.

For a standard WordPress site, this is helpful. For WooCommerce, it is transformative. A product page can execute 150-200 database queries. Product metadata (attributes, variations, prices), category lookups, related products, review counts, stock levels, tax rates, shipping zones — every one of these is a query. Without object caching, each page load repeats all of them. With Redis, the vast majority are served from memory.

What Redis actually speeds up

The honest answer is “the repeated reads”. WooCommerce performs three broad categories of database operation, and Redis helps with only one of them:

1. Repeated reads — Redis excels here

Queries that return the same result for many requests:

• Product data — get_post(), get_post_meta() for product ID X returns the same thing until the product is updated
• Tax rates — the tax rules for a given location rarely change
• Shipping rules — shipping methods and rates for a given zone
• Site options — get_option() results are almost always cacheable
• User meta — for logged-in customers, meta queries hit the same data repeatedly
• Terms and taxonomies — category and tag lookups

These are the bread-and-butter of Redis wins. On a typical WooCommerce page load with Redis enabled, 80-95% of database queries are served from Redis instead of MySQL.

2. Unique writes — Redis doesn’t help

Operations that must hit the database because they are writing or reading genuinely unique per-request data:

• Order creation — wp_insert_post() and the HPOS order insert must write to disk
• Stock level updates — every purchase decrements stock
• Payment records — transaction records must be written
• Session data — unique per user per session
• Cart data — unique per user

Redis doesn’t accelerate these. It doesn’t make writes faster, and it shouldn’t — caching writes would cause data loss.

3. Cache-busted reads — Redis helps once, then invalidates

Some reads happen against data that changes frequently. Redis caches them, but the cache is invalidated every time the data changes:

• Stock levels — cached until the next purchase, then invalidated
• Latest orders — cached until a new order arrives
• Customer last order — invalidated on every new order by that customer

For these, Redis provides partial relief — the first customer to request the data hits MySQL, subsequent requests within the cache window are served from Redis.

The typical performance picture

On a WooCommerce store that enables Redis for the first time, expect:

Stores with heavy plugin stacks (subscriptions, multi-currency, dynamic pricing) typically see larger improvements because each plugin adds repeated queries that Redis handles cleanly.

Installing and configuring Redis

The mechanics vary by hosting environment. On managed hosting with Redis available at the server level (LiteSpeed + Redis is a common setup), the plugin typically handles the drop-in file installation and Redis connection automatically.

On self-managed environments, the sequence is:

# Install Redis server
apt install redis-server

# Install the PHP Redis extension
apt install php-redis

# Start Redis and enable on boot
systemctl enable --now redis-server

Then install a WordPress Redis plugin. Recommended options:

• LiteSpeed Cache — if you’re on LiteSpeed, the plugin’s built-in Redis object cache is the simplest path. WooCommerce-aware by default.
• Redis Object Cache (by Till Krüss) — the most widely-used standalone Redis plugin for WordPress. Well-maintained, broad compatibility.
• W3 Total Cache — includes Redis object cache among many other features. More complex than needed if Redis is all you want.

After installation, confirm Redis is active via Tools → Site Health → Info → Drop-ins (look for object-cache.php) or:

wp cli info --fields=global_config_path
redis-cli
> INFO stats

The critical WooCommerce-specific configurations

Default Redis configurations work for WordPress but often miss WooCommerce-specific issues. Four settings worth checking:

1. Dedicated database or key prefix

If Redis is shared with other applications (staging environment, another WordPress site, Magento, etc.), either assign WooCommerce a dedicated Redis database (0-15 available) or set a distinctive key prefix. Without isolation, cache keys can collide between applications — producing surreal bugs where clearing one site’s cache affects another.

In your plugin’s settings:

• LiteSpeed Cache: Redis database number (0-15)
• Redis Object Cache: WP_REDIS_PREFIX constant in wp-config.php

2. Appropriate maxmemory policy

Redis defaults to noeviction — when memory fills, Redis refuses writes. For WordPress object caching, this is wrong. You want allkeys-lru — when memory fills, Redis evicts the least-recently-used keys.

In /etc/redis/redis.conf:

maxmemory 512mb
maxmemory-policy allkeys-lru

Restart Redis after changing. Without this, you get silent cache write failures when Redis fills up, which manifests as slow pages with no obvious cause.

3. Persistence off for pure object cache

If Redis is used purely as a WordPress object cache (not as session store or queue), disabling persistence speeds it up significantly. Persistence writes cached data to disk, which is wasted work for data that is cacheable but disposable.

save ""
appendonly no

If Redis also stores sessions or queues (e.g. for WooCommerce session storage — see below), keep persistence enabled.

4. WooCommerce session storage

WooCommerce stores cart and session data in wp_wc_session, the database by default. Many Redis plugins offer the option to move session storage to Redis instead. This is typically a strong win — cart and session operations become fast, and the wp_wc_session table doesn’t accumulate thousands of rows.

In LiteSpeed Cache: enable “Session Object Cache” under Object Cache settings. In Redis Object Cache plugin: set WP_REDIS_SALT and use session handler hooks.

Monitoring and debugging

A Redis setup that looks correct can still underperform. Three metrics worth watching:

Hit ratio

The percentage of cache lookups that found the requested key. A healthy WooCommerce Redis setup runs at 90%+ hit ratio. Check via:

redis-cli INFO stats | grep keyspace

A hit ratio below 80% usually indicates one of: insufficient Redis memory (keys being evicted too quickly), too many cache-busting operations (heavy writes invalidating the cache), or a misconfigured plugin that’s bypassing Redis on too many queries.

Key count

Dramatic jumps in key count often indicate cache-key bugs — plugins generating unique keys for data that should be cached consistently. Monitor via:

redis-cli INFO keyspace

Evictions

Evictions happen when Redis is full and has to drop keys. Some evictions are normal; many evictions means your maxmemory is too low or LRU isn’t protecting useful keys:

redis-cli INFO stats | grep evicted_keys

Common Redis problems on WooCommerce

Four patterns that cause Redis to underperform:

Stale cache after orders — If product stock levels appear wrong after purchases, Redis may be caching stock data without proper invalidation. This is usually a plugin bug, not a Redis bug. Check that your caching plugin claims WooCommerce compatibility specifically, not just WordPress compatibility.

Checkout errors referencing cache — Checkout errors with messages about “cache” or “session” often indicate Redis session storage is enabled but misconfigured. Either correctly configure session handling in Redis or disable session caching and use database sessions.

Massive Redis memory growth — If Redis memory climbs steadily and never drops, some plugin is storing data in Redis without TTL expiration. Monitor key patterns via redis-cli --bigkeys and investigate the largest contributors.

Cache clear clears everything — WordPress’s “clear all caches” operation on some plugins flushes Redis entirely. This is correct behaviour but means the next few page loads hit the database. Consider granular cache invalidation if this is an operational issue.

When Redis isn’t enough

Redis dramatically speeds up the reads it caches but cannot fix everything. If Redis is correctly configured and WooCommerce is still slow, the likely culprits:

• Database writes are bottlenecked — checkout, order creation, stock updates. Redis doesn’t help here; the fix is faster storage (NVMe) and adequate database resources.
• PHP execution is slow — the application code itself takes time. Redis just removes database wait time; it doesn’t speed up the PHP that’s using the data.
• External API calls — payment gateway, tax services, shipping calculators. These run synchronously during checkout and aren’t affected by Redis.
• Plugin bloat — the WooCommerce stack is too heavy regardless of caching. See our WooCommerce performance guide for the full picture.

Redis is a huge part of a fast WooCommerce store, but it is not the whole picture. For the systemic view, see our guide to diagnosing slow WooCommerce stores and the performance audit checklist for a structured review.