Skip to content

How to enable Redis object cache for WordPress (and when it helps)

By SharedGridPublished 8 min read

SharedGrid logo on a blue grid background

Redis comes up in almost every conversation about WordPress speed. It’s often sold as a magic switch, and it isn’t one. On the right site it makes a real difference. On the wrong site you won’t notice it at all.

This guide explains what a Redis object cache actually does, how it differs from page caching, when it’s worth turning on, and how to enable it with either LiteSpeed Cache or the Redis Object Cache plugin.

Page cache vs object cache vs browser and CDN cache

WordPress sites usually have several layers of caching. They do different jobs, so it helps to know which is which.

Page cache. When someone visits a page, WordPress runs PHP, queries the database and builds the HTML. A page cache saves that finished HTML and hands the same copy to the next visitor, so WordPress doesn’t have to run at all. On LiteSpeed servers, the LiteSpeed Cache plugin does this at the web server level. For fairly static pages, the WordPress documentation says page caching “can improve performance several hundred times over”.

Object cache. This sits one level down. While WordPress builds a page, it asks the database for the same things again and again: your settings, menus, user details, product data. WordPress has a built-in object cache (WP_Object_Cache) that remembers those answers, but by default it’s non-persistent. It’s thrown away at the end of every request, so the next request starts from scratch.

A persistent object cache keeps those answers between requests. Redis is an in-memory store that’s very good at this job. With Redis connected, WordPress can fetch the data from memory instead of asking the database again.

Browser and CDN cache. These keep copies of your images, CSS and JavaScript closer to the visitor: in their browser, or on a content delivery network’s servers around the world. They make repeat visits and far-away visitors faster, but they don’t help WordPress build a page any quicker.

Redis vs page cache: which one do you need?

Most sites need a page cache first. If a page can be cached as finished HTML, that’s always the fastest way to serve it, and Redis isn’t involved.

Redis helps with the requests a page cache can’t handle. Those are pages that have to be built fresh for each visitor, such as:

  • WooCommerce shops: baskets, checkout and “my account” pages are personal, so they’re usually excluded from the page cache. Our WooCommerce hosting page covers how we handle this for shops.
  • Membership and course sites: logged-in members see their own content, so most of their pages are built fresh.
  • Sites with lots of logged-in users: forums, intranets and community sites.
  • Busy admin areas: editors working in the dashboard all day, large product catalogues and big imports.
  • Large sites: plenty of posts, options, terms or users means more database work per request.

Where it doesn’t help much: a simple brochure site or blog that’s already page-cached. Nearly every visitor gets the cached HTML, so WordPress rarely runs and there’s little for Redis to speed up. It won’t do any harm, but don’t expect a visible change.

It’s also worth knowing that a persistent object cache isn’t a cure-all. A slow plugin that runs thousands of lookups per page will still be slow. Redis just makes each lookup cheaper.

Before you start: check Redis is available on your hosting

Redis is a separate service that runs on the server. A plugin can’t install it, so it has to be provided by your host.

On SharedGrid, Redis is included on every web hosting plan and every managed WordPress plan. On reseller hosting it’s included on the Enterprise plan. Our hosting runs on the Enhance control panel with LiteSpeed.

You’ll need the connection details for your site. That’s usually either:

  • a host and port, such as 127.0.0.1 and 6379 (Redis’s standard port), or
  • a socket path, a file on the server that the plugin connects through.

You may also need a password and a database number. If you’re not sure which details to use, or whether Redis is switched on for your site, ask our support team and we’ll confirm.

Choose one plugin, not both

WordPress uses a persistent object cache through a single “drop-in” file, wp-content/object-cache.php. Only one plugin can own that file. If you set up object caching in two plugins, they’ll fight over it.

  • If you already use LiteSpeed Cache for page caching (most sites on LiteSpeed servers do), use its built-in object cache setting. One plugin, one place to look.
  • If you use a different page cache, or want Redis-specific diagnostics, use Redis Object Cache by Till Krüss, and leave LiteSpeed Cache’s object cache turned off.

How to enable Redis with LiteSpeed Cache

LiteSpeed Cache doesn’t store objects itself. It connects WordPress to an external cache, such as Redis or Memcached.

  1. In WordPress, go to LiteSpeed Cache › Cache and open the Object tab.
  2. Turn Object Cache on.
  3. Set Method to Redis. The default is Memcached, so this is easy to miss.
  4. Set Host to your Redis host, such as 127.0.0.1 or localhost. If you’ve been given a socket, enter the socket path here instead.
  5. Set Port. The default is 11211, which is Memcached’s port, so change it to your Redis port (usually 6379). If you’re using a socket, LiteSpeed’s documentation says to set the port to 0.
  6. If you were given a password or database number, fill in Password and Redis Database ID.
  7. Leave Persistent Connection and Cache WP Admin on unless you have a reason to change them.
  8. Save your changes.

The Status box at the top of the Object tab then shows whether the plugin can reach Redis. You want the Redis extension to show as enabled and the connection test to say Passed.

How to enable Redis with the Redis Object Cache plugin

If you’ve chosen the Redis Object Cache plugin instead:

  1. In Plugins, add a new plugin. Search for Redis Object Cache, install the one by Till Krüss and activate it.
  2. Go to Settings › Redis and enable the object cache. This adds the object-cache.php drop-in.
  3. Check the status. If it says Connected, you’re done.

If it says Not connected, the plugin couldn’t find Redis at its default address (127.0.0.1:6379, database 0). Add your connection details to wp-config.php, above the line that says /* That's all, stop editing! Happy publishing. */:

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'yoursite' );

For a socket connection, use these instead of the host and port:

define( 'WP_REDIS_SCHEME', 'unix' );
define( 'WP_REDIS_PATH', '/path/to/redis.sock' );

Replace the example values with the details from your host. If you have SSH access, the plugin also adds WP-CLI commands: wp redis status shows the connection and diagnostics.

How to check Redis is working

Site Health. Go to Tools › Site Health. Since WordPress 6.1, larger sites without a persistent object cache see the recommendation “You should use a persistent object cache”. Once Redis is connected, it changes to “A persistent object cache is being used”.

Smaller sites may see “A persistent object cache is not required” instead. That’s WordPress agreeing that your site is small enough not to need one.

The plugin’s status. In LiteSpeed Cache, check the Status box on the Object tab. In Redis Object Cache, check Settings › Redis, which shows the connection status, diagnostics and recent response times.

Your own experience. The clearest sign is usually in the places Redis is meant to help: a quicker dashboard, faster product searches and quicker checkout pages.

Troubleshooting Redis object cache

Connection refused or connection test failed

The plugin can’t reach Redis. Check these in order:

  • The port. In LiteSpeed Cache, the most common mistake is leaving the port at 11211 (Memcached) with the method set to Redis.
  • Host and socket. Make sure you’re using the exact host or socket path your host gave you. With a socket in LiteSpeed Cache, the port should be 0.
  • Password and database. If Redis needs a password, the connection fails without it.
  • Redis is running. If everything looks right, ask your host to check that Redis is enabled for your site.

Stale data

Sometimes a change doesn’t show up straight away, such as a setting that seems not to save or an old value in the dashboard. That usually means the object cache is holding an old copy. LiteSpeed’s documentation notes that Cache WP Admin can occasionally return stale data in the dashboard. If it keeps happening, try turning that setting off.

Stale data can also come from a plugin that doesn’t work well with object caching. Both plugins let you exclude specific cache groups. LiteSpeed Cache calls this Do Not Cache Groups.

If several WordPress sites share one Redis server, give each one its own database number and prefix. Otherwise they can read each other’s data. Redis Object Cache’s own FAQ says you must set a separate WP_REDIS_DATABASE and WP_REDIS_PREFIX for each site.

Flushing the cache

Flushing empties the object cache, and WordPress rebuilds it as pages are requested. It’s safe, because the data in an object cache can always be regenerated from the database.

  • Redis Object Cache has a Flush Cache button on its settings page.
  • With SSH, wp cache flush empties the object cache whichever plugin you use. On a multisite network it usually flushes every site at once.

The site may be a little slower for a moment afterwards while the cache warms up again.

Questions

Do I need Redis if I already use LiteSpeed Cache?

For a simple site, probably not. LiteSpeed’s page cache does most of the work. For shops, membership sites and busy admin areas, yes: Redis speeds up the pages that the page cache can’t store.

Is Redis the same as page caching?

No. A page cache stores finished pages. Redis stores the smaller pieces of data WordPress uses to build pages. They work well together.

Can Redis break my site?

It shouldn’t, but a misconfigured cache can show stale data or cause odd behaviour with some plugins. If something looks wrong, flush the cache. Turning object caching off returns WordPress to its normal behaviour.

Should I use Memcached instead?

Both are persistent object caches, and LiteSpeed Cache supports either one. Use whichever your host provides. On SharedGrid, that’s Redis.

Let us set it up for you

If you’d rather not configure any of this yourself, SharedGrid’s managed WordPress hosting comes with caching set up, including Redis object caching on every plan. It runs on LiteSpeed with a Bunny.net CDN, so your site gets every layer described above without you touching a setting.

Checked against WordPress and LiteSpeed documentation, November 2026.

Keep reading.

WordPress

Managed WordPress with Bunny.net CDN

If you’re searching for Managed WordPress with CDN integration, SharedGrid has you covered with our new platform, powered by Bunny.net CDN.

WordPress, without the worry.

Managed WordPress with Redis, LiteSpeed caching, twice-daily backups and a free CDN.