← All postsHosting

Redis object cache for WooCommerce, and why it matters

By · Published September 25, 2026 · 4 min read

Redis object cache for WooCommerce, and why it matters
Photo: Sejio402 / Pexels

Disclosure: this post contains affiliate links to Cloudways. If you start a plan through one, StoreToNative may earn a commission at no extra cost to you. Everything technical below applies to any host that offers Redis.

If you make one performance change to a WooCommerce store this year, make it this one. It is the cheapest, it is the largest, and it is the one that specifically helps the traffic a mobile app generates.

Page cache and object cache are different things

This confusion is the reason so many stores do not have an object cache.

A page cache stores finished HTML. A visitor requests a category page, the cache serves the stored copy, PHP never runs. Enormously effective for anonymous visitors on pages that do not change per person.

An object cache stores the ingredients: the results of individual database queries and computed values, so PHP does not have to recompute them on requests the page cache cannot serve.

The distinction matters because a WooCommerce store’s most important traffic is exactly what a page cache cannot help with:

  • Cart, checkout, my-account — personalized, never cached
  • Logged-in customers — personalized
  • REST API responses — what your mobile app consumes, and never page-cached

So a store with excellent page caching can still be slow at every moment that matters. See why your REST API is slow.

What WordPress does without one

WordPress has an object cache by default, but it is non-persistent — it lives for the duration of a single request and is thrown away.

That means every request recomputes the same things: your options table, term relationships, post meta, WooCommerce’s own settings and product data lookups. A single WooCommerce product listing request can run hundreds of queries, most of which produce identical results to the previous request seconds earlier.

A persistent object cache — backed by Redis or Memcached — keeps those results in memory across requests. The second request does not repeat the first one’s work.

Why WooCommerce benefits more than a blog

Three reasons specific to commerce:

The options table is large and hot. WooCommerce, its extensions and payment gateways store a great deal in wp_options, and much of it is autoloaded on every request.

Product meta is heavy. Prices, stock, attributes, variation data — all in post meta, all queried constantly.

Nothing is anonymous for long. Shoppers log in, carts exist, checkout happens. The page cache steps aside exactly when the store starts making money.

Add a mobile app and it compounds: every API request runs the full path, several fire per app launch, and none of them are page-cacheable.

Turning it on

Two components: a Redis server, and a WordPress drop-in that tells WordPress to use it.

On managed cloud hosting this is usually a switch rather than an installation. Cloudways ships Redis and Memcached built in, and includes Object Cache Pro on its plans — which is the well-regarded commercial implementation most people otherwise buy separately, and the one worth using if it is included. They also bundle Object Cache Pro + Relay on their Autonomous product.

The steps, generically:

  1. Enable Redis on the server (a toggle on managed hosts; an install on your own).
  2. Install the object cache plugin — Object Cache Pro if you have it, Redis Object Cache otherwise.
  3. Enable the drop-in. The plugin writes wp-content/object-cache.php. This file is the actual mechanism; without it nothing is cached.
  4. Confirm the connection. The plugin’s status screen should say connected.
  5. Measure again.

Use one object cache. Redis or Memcached, not both.

Proving it works

An object cache plugin that is installed but not connected looks almost identical to one that is working. Verify with numbers, not screens.

Before enabling, time an API request from outside your network:

curl -o /dev/null -s -w "%{time_total}\n" \
  "https://yourstore.com/wp-json/wc/v3/products?per_page=20&consumer_key=…&consumer_secret=…"

Run it five times, take the median. Then enable, warm the cache with a couple of requests, and run it five more times.

A meaningful improvement on an uncached WooCommerce store is common — often the largest single change available. If nothing moves, the cache is not actually connected, and that is the thing to fix before looking anywhere else.

Also check wp-admin, which is never page-cached and therefore an honest reflection of your server’s real speed.

The three things that go wrong

1. Redis runs out of memory and evicts constantly. Symptom: the cache is connected but the hit rate is poor. Fix: more memory for Redis, or a smaller cache footprint. Most object cache plugins expose a hit-rate figure — look at it.

2. Stale data after a deploy or import. Rare, but real. Flushing the object cache is safe and instant; make sure you know how, before you need to.

3. A plugin that caches badly. Some plugins store enormous transients that pollute the cache. If your hit rate is bad and memory is full, look at what is being stored.

What to do after the object cache

In order of remaining value:

  1. PHP version. Move to a current 8.x. On Cloudways this is a per-application selector across 7.4, 8.0, 8.1, 8.3 and 8.4.
  2. Image sizes. Make sure the app is receiving thumbnail-sized images, not 3 MB originals.
  3. Plugin audit. Find the two or three that add the most time per product query — on staging, never production.
  4. Database RAM, if filtered catalog queries are still slow.
  5. Server region, if your customers are far from your server.

Each of those is worth doing. None is worth doing before the object cache, because the object cache is usually bigger than all of them together.

Related reading