WordPress Object Caching Explained: Redis, Memcached, and Why Page Caching Isn't Enough

Let me paint you a picture. You've got a WooCommerce store. You installed a page caching plugin. Your homepage loads in under a second. Life is good.

Then a customer logs in. They add something to their cart. And suddenly your Time to First Byte shoots up to 4 seconds. The site feels like it's running through mud.

What happened? Page caching turned itself off. That's what happened.

Page caching only works for anonymous visitors. The moment WordPress detects a logged-in user, a cart cookie, or any kind of personalized content, it skips the cache and hits the database for everything. Every widget, every option, every user meta query. All of it goes straight to MySQL.

I see this catch people off guard constantly. They install WP Super Cache or W3 Total Cache, run a speed test while logged out, celebrate the fast results, and call it a day. Then their actual customers are stuck waiting on a server that's drowning in database queries.

That's where object caching comes in. And if you're running any kind of membership site, LMS, or online store, you genuinely can't skip this.

What Object Caching Actually Does

The concept is dead simple. Instead of caching the final HTML page, object caching stores individual database query results in your server's RAM.

WordPress makes a lot of redundant queries. On every single page load, it asks the database for your site title, your active plugins, your widget configuration, the current user's session data. Stuff that barely ever changes. Without object caching, MySQL answers those same questions over and over, thousands of times a day.

With object caching enabled, WordPress checks RAM first. If the answer is already there, it never bothers the database. The query takes microseconds instead of milliseconds. Multiply that across hundreds of queries per page load and the difference is massive.

I had a client's WooCommerce site that was running about 847 database queries per page load on the My Account page. After setting up Redis, that dropped to around 190. Same page, same functionality, just way less pressure on MySQL.

So, Redis or Memcached?

People overthink this decision. For a single WordPress site, honestly, either one works fine.

I personally lean toward Redis for a couple of reasons. It supports data persistence, so if your server reboots, Redis can reload its cache from disk instead of starting completely cold. Memcached doesn't do that. It just dumps everything on restart and you're back to square one until the cache warms up again.

Redis also supports more complex data types, which some plugins take advantage of. And the ecosystem around Redis feels more actively maintained in the WordPress world, with plugins like Redis Object Cache by Till Kruss getting regular updates.

But look, if your host only offers Memcached, don't sweat it. The performance gains are nearly identical for typical WordPress workloads. Use what's available.

Setting It Up (The Short Version)

There are three pieces to this puzzle:

First, the caching service itself (Redis or Memcached) needs to be running on your server. This is a server-level thing. If you're on shared hosting, you might be out of luck. Most managed WordPress hosts like Cloudways, Kinsta, or RunCloud have a toggle for it in their dashboard.

Second, PHP needs the matching extension installed. Redis needs php-redis (or phpredis). Memcached needs php-memcached. Your host usually handles this, but if you manage your own VPS, you'll need to install and enable it yourself.

Third, WordPress needs a drop-in file called object-cache.php in your wp-content directory. This file tells WordPress "hey, stop using the default in-memory cache that dies after every request, and start using the persistent one on the server." Plugins like Redis Object Cache or W3 Total Cache can create this file for you automatically.

The Part Where Most People Get Stuck

You installed a Redis plugin but nothing changed? Yeah, that happens a lot.

The plugin is just the WordPress side of things. If the actual Redis server isn't running on your Linux box, the plugin has nothing to connect to. It'll silently fall back to the default WordPress cache (which isn't persistent) and you won't notice anything different.

If you're using my Server Info plugin, you can check the dashboard to see whether the PHP extensions for Redis or Memcached are actually loaded. It'll tell you instantly. Saves you the trouble of SSH-ing in and running php -m | grep redis to figure it out.

Another common issue: people have Redis running but the object-cache.php drop-in file is missing or outdated. Check your wp-content folder. If that file isn't there, nothing is being cached persistently.

Is It Worth the Effort?

Absolutely. A properly configured object cache can handle 60-80% of your database queries before they ever reach MySQL. On a busy WooCommerce store or a BuddyPress community site, that's the difference between a snappy experience and a server that falls over during a traffic spike.

Page caching is great for what it does. But it's only half the picture. Get your object cache running and your logged-in users will finally stop wondering why your site is so slow.