Maybe Site Health has started recommending a persistent object cache. Maybe your host’s panel has a Redis switch you have never touched. Or a developer looked at your slow shop and said “you need Redis”. Nobody quite explained what it would change, and whether a small site needs it at all.
A Redis object cache for WordPress is a narrow tool. It does one job very well, helps some sites a lot and others hardly at all, and depends on your hosting more than on any plugin. So start by working out which kind of site you have. For plenty of small sites, the honest answer is that it will not change much.
Signs your site is the kind that benefits
Start here, because this decides whether the rest is worth your time.
- Pages are fast for anonymous visitors but slow for logged-in members, customers or staff.
- You run a WooCommerce store, especially one with many products, variations or extensions, and cart, account and checkout pages feel heavy.
- You run a membership site, online course, forum or directory where most visitors log in.
- The admin area is sluggish when editing products or posts, and the hosting itself is reasonable.
- Query Monitor or your developer shows the same database queries repeating on every page load.
If your site is a ten-page brochure site where nobody logs in except you, and a page cache already serves almost every visit, a persistent object cache will make little visible difference. That is not a failure of Redis. The page cache has already removed the work it would have sped up.
What an object cache stores, and how it differs from a page cache
A page cache, covered in our overview of the main types of website cache, stores finished HTML pages. An object cache works one level down. It stores the pieces WordPress uses to build a page: the result of a database query, a list of menu items, a product’s details, a plugin’s settings, a value worked out by some slow code.
WordPress always has an object cache built in. The catch is that by default it lives only for the length of one request. WordPress fills it while building the page, reuses those values within the same page load, and then throws everything away. The next request starts empty and asks the database all the same questions again.
A persistent object cache keeps those values between requests, in memory, using a separate piece of software. Redis and Memcached are the two common ones. With it in place, the second request can read many answers from memory instead of from the database. WordPress also stores transients, its short-term saved values, in the object cache instead of the database when a persistent one is available.
The important difference: a page cache is skipped for logged-in users and shoppers, but the object cache keeps working for them. That is why it matters most on exactly the pages a page cache cannot touch. If your main complaint is that the site slows down once you sign in, our post on why WordPress is slow for logged-in users covers the other causes too.
The Site Health recommendation
Recent versions of WordPress can show a Site Health recommendation to use a persistent object cache. It is not shown on every site. WordPress only raises it when the site looks large enough to benefit, judged by things like the amount of content and data it holds, and the notice often mentions whether your host appears to support Redis or Memcached.
Treat it as a suggestion, not an error. Nothing is broken. It is WordPress saying that sites of your size usually do better with one. If you cannot get one on your current hosting, the site will carry on working as before.
What a Redis object cache for WordPress needs from your host
This is where most attempts stall. Three pieces are needed, and only the last is a plugin:
- A Redis server running on the hosting, or reachable from it. On a VPS or cloud server it can be installed. On shared hosting it has to be offered by the host, sometimes as a per-account service you enable in the panel.
- A way for PHP to talk to it, usually the PhpRedis extension. Some plugins can use a PHP library instead when the extension is missing, at some cost in speed.
- A plugin that adds the drop-in. WordPress looks for a file called object-cache.php in wp-content. Redis Object Cache, LiteSpeed Cache, W3 Total Cache and some host plugins can install one. Only one should be in place.
Questions worth asking your host before you start:
- Is Redis or Memcached available on my plan, and how do I enable it?
- Is it dedicated to my account, or shared with other customers?
- How much memory does it have, and what happens when it fills up?
- Do you recommend a particular plugin, or do you install the drop-in yourselves?
If the answer to the first question is no, do not try to work round it with a plugin that stores the “object cache” on disk. On a lot of hosting that brings little benefit and can even be slower than letting the database answer.
Setting it up in outline
Exact steps depend on the host, but the shape is the same:
- Take a backup, or test on a staging copy first.
- Enable Redis in the hosting panel, or confirm with the host that it is running, and note the connection details if they are not the defaults.
- If several WordPress sites share the same Redis, give each one its own key prefix in wp-config.php. The plugin’s documentation names the setting. Without it, sites can read each other’s cached data, which shows up as one site’s menu or settings appearing on another.
- Install one object cache plugin and enable it. It writes the object-cache.php drop-in.
- Check the plugin’s status screen shows it is connected.
If you already use LiteSpeed Cache or W3 Total Cache, check whether their object cache option fits your hosting before adding a second plugin for the same job.
Is it actually working?
- The plugin status. It should say connected, and many plugins show a hit ratio: the share of requests for cached values that were answered from Redis. A healthy cache has a high hit ratio after it has had time to fill.
- Query Monitor. This free plugin shows, for each page load, how many database queries ran and whether a persistent object cache is in use. Compare a logged-in product or account page before and after. Fewer queries and less database time is the result you want.
- Your own timing. Note how long a few logged-in actions take before you start: opening an order in the admin, loading the cart with items in it, opening a member dashboard. Time them again afterwards.
Do not expect anonymous speed tests to change much. They mostly hit the page cache, which never asks Redis anything.
Problems that come with it
Stale values after direct database changes
WordPress keeps the object cache in step when changes go through WordPress itself. Changes made straight in the database, by a migration tool, a search-and-replace script or a developer running SQL, bypass that. The cache then holds old values. Flush the object cache after any change made that way. Every object cache plugin has a flush button.
Memory running out
Redis keeps everything in memory. When it fills, it either refuses new data or removes old entries, depending on how it is configured. A well-configured setup removes the least recently used values and carries on. A badly configured one can start throwing errors. This is a host-side setting, so ask.
Redis going away
If Redis is switched off or the host moves your account while the drop-in is still in wp-content, the result depends on the drop-in. Good ones fall back to the database quietly. Others can produce errors. Disable the object cache in the plugin, which removes the drop-in, before switching Redis off or moving hosts.
It hides slow code rather than fixing it
An object cache makes repeated slow work cheaper. A plugin that runs a very heavy query will still run it every time the cached value expires or is cleared. If one plugin is responsible for most of the database time, finding and replacing it may help more than any cache.
Object cache, opcode cache, page cache: which first?
For most WordPress sites the order is page cache first, because it helps the largest number of visits, then a check that OPcache is enabled, explained in our note on the PHP opcode cache, then a persistent object cache for sites with logged-in traffic or a store. On a busy shop the object cache moves up the list. For how stores differ more generally, see what makes a WooCommerce site slow. Our website speed and performance guide lays out where server-side caching fits among everything else.
Frequently asked questions
Is Redis better than Memcached for WordPress?
For most small sites the difference matters less than whether the host supports either one well. Both keep cached values in memory, and WordPress plugins exist for each. Redis is the one you will see mentioned more often in hosting panels and WordPress plugins, and it can keep data across restarts if configured to. Use whichever your host supports properly.
Can a persistent object cache break my site?
It rarely breaks a site, but it can cause confusing behaviour. Sites sharing one Redis without separate key prefixes can show each other’s data, and direct database edits can leave stale values until the cache is flushed. Removing Redis while the drop-in file is still in place can also cause errors on some setups.
Does an object cache replace my caching plugin?
No. A caching plugin usually provides a page cache, which stores whole pages for anonymous visitors. An object cache stores smaller pieces of data and helps the requests a page cache cannot serve. They work together, and some caching plugins can manage both, but one does not replace the other.
How do I remove Redis object caching safely?
Disable the object cache from the plugin that installed it, which removes the object-cache.php file from wp-content, then deactivate the plugin. Only after that should Redis be switched off in the hosting panel. Doing it in the reverse order can leave WordPress trying to reach a cache that is no longer there.
Whether Redis is worth it on your hosting is a question for measurement rather than opinion. The server response review in our website speed service covers it, timed on your logged-in pages, and if the hosting turns out to be the limit you will be told plainly.
Next in this series: PHP OPcache Explained: The Cache Your Host Runs for You
