Redis is a common choice when a WordPress store needs a persistent object cache: an in-memory store where WordPress keeps the results of database queries between page views. It helps exactly the pages a page cache can’t handle, such as cart, checkout, My account and the admin.
This guide walks through the setup step by step with the Redis Object Cache plugin, what to watch for when several sites share the same Redis, and how to check that it works.
What Redis does for a WooCommerce store
Without a persistent object cache, WordPress only remembers query results while a single page is being built. The next page view asks the database the same thing again. With Redis, the results stay in memory, so product data, settings and much more can be fetched from there instead.
Redis isn’t a page cache. It doesn’t speed up pages that already come from the page cache, but it makes the pages that have to be built every time faster to build. How the different kinds of cache work together in a store is covered in our guide to WooCommerce caching.
What you need
- A Redis server: Many hosting providers offer Redis, some as an add-on to the plan. Ask your provider, and get the host (or socket), port and any password. If you run your own server, Redis has to be installed and secured so it isn’t reachable from outside.
- The PHP extension for Redis: The plugin can use the PhpRedis extension or a pure-PHP library. The extension is the fastest. Ask your provider whether it’s installed.
- A plugin: Here we use the free Redis Object Cache from the WordPress plugin directory. There are others, including paid ones. We’ve compared several of them in our object cache plugin benchmark for WooCommerce.
Setup step by step
Try it on a copy of the store first. Then go through the same steps on the live store.
1. Settings in wp-config.php. Add the connection details above the line that tells you to stop editing. Change the values to the ones your hosting provider gave you:
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_PASSWORD', 'your-password' ); // only if Redis requires one
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'mystore_' );2. Install the plugin. Install and activate Redis Object Cache under Plugins → Add New.
3. Turn on the object cache. Go to Settings → Redis, and click the button that enables the object cache. The plugin then places the file object-cache.php in wp-content. That’s the file WordPress uses to talk to Redis. With WP-CLI, wp redis enable does the same.
4. Check the status. On the same page, the status should show that the plugin is connected and the drop-in is valid. Under Tools → Site Health, the recommendation to use a persistent object cache goes away.
Several sites on the same Redis
If several sites share the same Redis server, each site needs its own prefix or its own database. Otherwise they can read each other’s data. That includes the copy of your store: if the copy and the live store use the same prefix and database, settings and product data from the copy can show up in the live store, and the other way around. Change WP_REDIS_PREFIX or WP_REDIS_DATABASE every time you make a copy.
Memory: what happens when Redis is full?
Redis can be given a limit on how much memory it may use, and has a rule for what happens when it’s reached. The default rule in the Redis configuration is noeviction: Redis rejects new data when the limit is reached, and then WordPress can’t store anything in the cache. For an object cache, the rule should instead be that the oldest or least used data is evicted, for example with the setting maxmemory-policy allkeys-lru. At a hosting provider, this is usually set up for you. Ask if you’re unsure.
Large autoloaded options take up room in Redis too, and have to be fetched on every page view. How to find and clean them up is in our guide to autoloaded options that have grown too large.
Does it work?
The plugin’s status page shows whether the connection is fine. Whether the cache is actually being used, you can see with Query Monitor: the overview shows the object cache hit rate, the share of lookups that came from Redis. It should be high as you click around the store. Then compare the time for cart, checkout and a heavy admin page with the time from before. Where the object cache fits when troubleshooting a slow store is covered in the caching section of the troubleshooting guide.
When something goes wrong
- Old data after a change directly in the database: Changes made outside WordPress, such as an import straight into the database or a site move, don’t reach the cache. Flush the cache afterward from the plugin’s page or with
wp cache flush. - No connection: Check the host, port and password, and ask your provider whether Redis is running.
- You want to turn it off again: Disable the object cache on the plugin’s page, or remove
object-cache.phpfromwp-content. WordPress then uses the database as before.
Frequently asked questions
Redis or Memcached?
Both can be used as an object cache in WordPress. Redis is what many hosting providers offer and what most object cache plugins support. Use whichever your hosting provider offers.
Can Redis make the store slower?
It can, if Redis runs on another server far away, so every lookup takes longer than asking the database. Redis should be close to the web server, ideally on the same machine or in the same data center.
Want help?
Redis is rarely hard to turn on, but it’s easy to overlook the prefix, the memory and copies of the store. If you’d like us to set it up or check your setup, read about optimizing your WooCommerce store. We take a free look at your store first and tell you what it will take.