Redis Object Cache in WordPress: A Straight Answer

A Redis object cache stores the results of database queries in memory so WordPress does not have to hit MySQL again for the same request. A page cache stores the entire rendered HTML output. If your site is mostly anonymous visitors reading static pages, page caching solves your speed problem. If your site has logged-in users, WooCommerce carts, membership content or heavy custom queries, object caching is what actually moves the needle, and page caching alone will leave you stuck.

What does a Redis object cache actually store?

WordPress runs thousands of small database queries on a typical page load. It asks for options, post meta, term relationships, user data, transients. Most of these queries return the same result over and over between database updates. An object cache sits between WordPress and MySQL and remembers the answer to "what are the site options" or "what is this user's meta" so the next request gets served from memory instead of triggering another SQL query.

Redis is the engine that holds this data in RAM. It's fast because reading from memory beats reading from disk every time, and because it skips the overhead of parsing and executing a SQL query. WordPress has a built in cache too, but it only lasts for a single page load. Redis persists that cache across requests, which is the entire point.

How is that different from page caching?

Page caching (Varnish, a plugin like WP Super Cache, or your host's built in full page cache) stores the finished HTML for a URL and serves that same file to every visitor who requests it. It never touches PHP or MySQL again until the cache expires. That's why page caching gives such dramatic speed improvements for anonymous traffic, and why it does nothing for logged-in users, because most page caches deliberately skip caching for anyone who is logged in or has items in a cart.

Object caching works underneath all of that. It speeds up the PHP execution and database queries that happen every single time a page has to be generated fresh, whether that's for a logged-in user, a search result, a WooCommerce checkout, or an admin dashboard. The two systems aren't competitors. On a well configured host they run together: page cache for anonymous front end requests, object cache for everything page cache can't touch.

Which sites actually benefit from Redis?

I've moved enough client sites onto Redis to know the pattern. Anywhere users log in, Redis helps. That means:

• WooCommerce stores, where every visitor technically has a session and a cart, meaning page cache exclusions kick in constantly
• Membership and LMS sites, where content is gated behind login
• Community sites with bbPress, BuddyPress, or any forum plugin
• Sites with heavy custom queries, complex Advanced Custom Fields setups, or plugins that run expensive meta queries
• Any site with a lot of logged-in admin or editor activity, because Redis speeds up wp-admin too

If you run a WooCommerce store and you've never touched object caching, this is genuinely one of the highest value changes you can make. Check our WooCommerce hosting guide before you assume the problem is your server tier rather than a missing cache layer.

Which sites see nothing from Redis?

A brochure site. Five pages, a contact form, no logins beyond the admin, updated twice a year. Page caching already handles nearly every request that matters, because nearly every visitor is anonymous and getting the same cached HTML. Adding Redis to a site like this isn't wrong, it just won't show you anything, because there's no repeated database load for it to eliminate.

I get asked about this constantly by clients who read a blog post somewhere and now want Redis on their static portfolio site. It does no harm, but don't expect a visible speed change. Spend the effort somewhere that matters, like image optimisation or trimming plugins, before chasing an object cache you don't need. Our plugins directory has genuinely useful tools for that kind of cleanup.

Which hosts include Redis object caching?

This varies a lot and it changes the buying decision more than people realise. Some managed WordPress hosts include Redis as standard on every plan, some gate it behind higher tiers, and plenty of budget shared hosts don't offer it at all because it needs a dedicated memory allocation per site rather than a shared resource pool.

When you're comparing hosts, don't take "we support caching" at face value. That phrase almost always means page caching. Ask specifically whether Redis (or Memcached, which does a similar job) is available, whether it's included at your plan level, and whether it's per site or shared across an entire server. Shared Redis instances on cheap hosting can cause odd cross contamination issues between sites, worth knowing before you commit. Our managed WordPress hosting comparison flags which providers include object caching properly and which charge extra or don't offer it at all.

How do you enable Redis object cache on WordPress?

If your host provides Redis, enabling it usually looks like this:

1. Confirm Redis is actually running on your server, check your hosting control panel or ask support directly
2. Install the official Redis Object Cache plugin from the WordPress plugin repository
3. Activate it, then go to Settings and click "Enable Object Cache"
4. The plugin will tell you if it connected successfully or if it can't reach Redis, which usually means your host hasn't enabled it or you need a connection detail from support

Some managed hosts handle this entirely on their end, dropping the connection file in automatically the moment you tick a box in their dashboard, no plugin install needed. Others expect you to do the plugin route above. Either way, don't assume it's on just because your host mentions Redis somewhere in their marketing copy. Verify it.

How do you check if Redis is actually working?

This is the step almost everyone skips, and it's the reason so many people think object caching "didn't do anything" when actually it was never connected in the first place.

The Redis Object Cache plugin has a status panel under Settings that tells you directly: connected or not connected, along with basic stats like hits and misses. If you see a healthy ratio of cache hits building up as you browse the site, it's working. If it says "not connected" or "using default WordPress object cache", Redis isn't doing anything for you regardless of what your hosting plan claims to include.

You can also check server side if you have terminal access, using the redis-cli command to confirm the Redis service is running and accepting connections. For deeper reading on how Redis itself works under the hood, Redis's own documentation is genuinely well written and worth ten minutes if you want to understand what's happening beyond the WordPress plugin layer.

What breaks when Redis is misconfigured?

The classic failure mode is stale data. If Redis isn't clearing cached objects when content actually changes, you'll see old prices on WooCommerce products, outdated menu items, or comments that don't appear until you manually flush the cache. This usually means a caching plugin conflict, or a theme/plugin combination that isn't properly hooking into cache invalidation.

Another common issue is memory limits. Redis has a maximum memory allocation, and if a busy site fills it up, Redis starts evicting older cached data to make room, which causes inconsistent performance that's hard to diagnose. If your host gives you a small shared Redis instance and your site is data heavy, ask about a larger allocation or a dedicated instance.

Security matters here too. An exposed Redis port with no authentication is a real risk, and it's the kind of thing that gets overlooked because caching feels like a purely performance topic rather than a security one. We cover this properly in Secure WordPress Hosting: What Actually Protects Your Site and in 6 WordPress Security Plugins Every Hosting Provider Should Know, both worth a read if you're running Redis on anything beyond a personal project.

Frequently asked questions

Do I need both page cache and object cache?

For most WordPress sites with any logged-in activity, yes. Page cache handles anonymous front end traffic, object cache handles everything else including wp-admin, WooCommerce, and logged-in sessions. They solve different problems, and running both is standard practice on well configured managed hosting.

Is Redis better than Memcached for WordPress?

They do broadly the same job of storing cached objects in memory, and both work fine with WordPress. Redis has more features, including persistence options and more data structures, which is why most managed hosts have standardised on it. But if your host only offers Memcached, that's not a reason to switch providers.

Will Redis fix a slow WooCommerce store on its own?

It will meaningfully help, particularly on category pages, cart, and checkout, but it isn't a complete fix on its own. A bloated theme, too many plugins, or an undersized server will still cause problems that Redis can't solve. Treat it as one piece of a proper performance setup rather than a silver bullet.

Can shared hosting run Redis?

Some shared hosts do offer it, but many don't, because it requires dedicated memory per account rather than the pooled resources shared hosting relies on. If Redis matters to your site, check explicitly before signing up rather than assuming it's included because the host mentions "caching" somewhere on their features page.