WooCommerce Redis object cache: what it speeds up and what it can't

A page cache hands stored HTML to anonymous visitors without starting PHP. An object cache works a level lower. WordPress core already has one, the WP_Object_Cache class behind wp_cache_get() and wp_cache_set(), but it is non-persistent by default: the developer reference says cached data lives in memory "only for the duration of the request." Every page load starts empty and asks MySQL again for the same options, product meta and term lists. WordPress loads the drop-in file wp-content/object-cache.php automatically whenever it exists, and a Redis plugin installs one, so every wp_cache_* call goes to Redis instead of a per-request array. Transients move with it: once an external object cache is in use, set_transient() writes to it and stops touching the wp_options table. The two caches stack rather than compete.

WooCommerce's developer documentation tells caching plugins to exclude three pages, Cart, Checkout and My Account, because they show information specific to the current customer, and to exclude the woocommerce_cart_hash, woocommerce_items_in_cart and wp_woocommerce_session_ cookies as well. Configured that way, a page cache hands the shopper to PHP from the first add-to-cart onward, while logged-in customers, trade buyers on account pricing and every wp-admin visit skip it entirely. That is the traffic closest to an order. An object cache serves it. WooCommerce's own session handler shows the mechanism. It calls wp_cache_get() in the wc_session_id group first and only runs a SELECT against the wp_woocommerce_sessions table on a miss. Without a persistent backend, every request is a miss. A slow dashboard has causes no cache touches; see why WooCommerce admin gets slow.

Both are in-memory key-value stores that the WordPress handbook lists side by side. For one store, who maintains the server decides it. SiteGround documents Memcached as its object cache, switched on in Site Tools under Speed > Caching and then in its Speed Optimizer plugin. Installing your own Redis on a host like that is the worse choice, because nobody there supports or monitors what you added. Where you control the server, or the host offers both, pick Redis: its WordPress plugin has 500,000+ active installs and its own WP-CLI commands, and Redis documents its eviction behavior down to the policy name, which the configuration below depends on.

On a VPS or a plan with a Redis server, use Redis Object Cache, Till Krüss's free plugin on wordpress.org. It needs WordPress 4.6 and PHP 7.2 at minimum. The plugin connects through PhpRedis, Predis or Relay and installs the object-cache.php drop-in itself, after which `wp redis enable` turns it on and `wp redis status` confirms the drop-in is in place and connected. Managed hosts package the same pieces:

• Kinsta sells a Redis add-on at $100 per month per site: a dedicated 2GB instance in the site's container, running Redis Object Cache
• Cloudways ships Object Cache Pro, the paid edition promoted on the free plugin's own page, and gives each application its own Redis database
• SiteGround runs Memcached, enabled first in Site Tools and then in Speed Optimizer, which shows a connection error if the server side is off

Most Redis setups that disappoint are misconfigured rather than broken. The plugin's constants go in wp-config.php, above the line that loads WordPress:

• `WP_REDIS_HOST` and `WP_REDIS_PORT`, defaulting to 127.0.0.1 and 6379; use `WP_REDIS_PATH` with the unix scheme when the host provides a socket
• `WP_REDIS_DATABASE`, a number from 0 to 15, one per site on a shared Redis server
• `WP_REDIS_PREFIX`, a readable prefix such as the store's domain, which replaced the older `WP_CACHE_KEY_SALT`
• `WP_REDIS_TIMEOUT` and `WP_REDIS_READ_TIMEOUT`, both one second by default
• `WP_REDIS_DISABLED`, which bypasses the cache without deleting the drop-in when you need to test with it off

The Redis side matters more. On 64-bit systems maxmemory defaults to 0, meaning no limit, so the cache grows until the machine runs short of RAM. Set one. Then set `maxmemory-policy allkeys-lru`, which Redis's documentation calls a good default when part of the data is read far more often than the rest. A store fits that exactly: the same options, menus and best sellers on every request. Leaving the default is the worse option, and it fails loudly. The default policy is noeviction, and once the limit is reached Redis returns errors on writes instead of making room. volatile-lru looks like a safer middle ground and is not one. Volatile policies evict only keys that carry an expiry, and the plugin's `WP_REDIS_MAXTTL` defaults to 0, so a large share of WordPress keys have none. Redis states that a volatile policy with no expiring keys behaves like noeviction. One more rule: staging and production on the same Redis server get separate databases and prefixes, so a cache flush on staging cannot empty production's.

Measure the pages Redis is supposed to help, before you turn it on. In a fresh browser session, add an item to the cart, then record TTFB, the wait until the server's first byte, on the cart and checkout pages five times each and keep the median. Google's web.dev puts a good TTFB at 0.8 seconds or less, as a rough guide. Repeat with Redis enabled and warm. Two readings back up the stopwatch:

• Query Monitor's Object Cache panel, which shows whether a persistent object cache is in use and the hit rate for that one request
• `redis-cli INFO stats`, where keyspace_hits against keyspace_misses gives the server-wide hit rate and evicted_keys counts what was thrown out

Take a scenario, not a measurement: cart TTFB drops from 1.4 seconds to 0.9 and the hit rate settles above 90%. Redis earned its place. A low hit rate with evicted_keys climbing means maxmemory is too small and the cache is discarding what it stored a moment ago. And when the hit rate is high but TTFB does not move, the time is being spent somewhere a cache cannot reach.

Redis makes repeated database reads cheap. Work that is not a database read costs the same with it as without it.

• Shared hosting with no Redis or Memcached server: the plugin installs, the drop-in cannot connect, and the fix is a plan that includes one, as our [hosting checklist](blog/woocommerce-hosting-what-matters) explains
• External calls at checkout: a live carrier rate, a tax API or a payment gateway request is network time unless the plugin caches its own responses
• Weight in the browser: heavy JavaScript, oversized images and third-party tags are untouched; see [why caching alone stops short](blog/wp-rocket-not-enough)
• Plugins that write with raw SQL and never call clean_post_cache() or wp_cache_delete(): the cached copy goes stale, and with WP_REDIS_MAXTTL at 0 nothing expires it, so a price or stock level fixes itself only after `wp cache flush`
• Plugins that keep settings or license state in transients: WordPress's own documentation warns that transients can vanish before expiry under an external object cache

Kinsta, which sells Redis, says it "will generally not help the load time" of static blogs and informational sites that already use page caching well. A store whose visitors mostly browse cached category and product pages anonymously, with one person in the admin, is in the same position, and faster PHP hosting should come before a $100-a-month add-on. WordPress's Site Health screen is no tiebreaker: since 6.1 it suggests a persistent object cache once the posts table passes roughly 1,000 rows, and 200 products with four variations each are already at that line.

Our free store audit checks whether a persistent object cache is connected, its maxmemory and eviction policy, the hit rate on cart and checkout, and whether slow TTFB there is a cache problem or a hosting one. Keeping it configured through updates is part of the Care Plan, from $150 a month; the rest is on pricing. We report what we measure and promise no number in advance.