Object caching is one of those WordPress optimizations everyone talks about but few operators actually understand. The idea is simple: instead of hitting the database every time someone loads a page, WordPress stores frequently accessed data—posts, user info, theme settings—in memory. When the same data is requested again, it’s served from RAM instead of MySQL.
That sounds like a win. And for many sites, it is. But object caching introduces moving parts—another service to monitor, another thing that can fail—and if your traffic or query load doesn’t justify it, you’re adding complexity for marginal gain.
What object caching actually does
Out of the box, WordPress uses a non-persistent object cache. That means data is stored in PHP memory for the duration of a single page load, then discarded. If the next visitor requests the same page, WordPress queries the database all over again.
A persistent object cache—typically Redis or Memcached—stores that data in memory across page loads. When WordPress asks for a post’s metadata or a list of recent comments, the cache serves it instantly. No database round trip.
This makes the biggest difference on sites with:
- High concurrent traffic (50+ visitors at once)
- Complex database queries (custom post types, meta fields, WooCommerce)
- Plugins that query the database on every page load (membership tools, dynamic content widgets)
If your site doesn’t fit those profiles, object caching won’t do much. A static homepage with 20 posts and light traffic won’t see a speed boost—you’re already fast enough.
When to skip it
Object caching adds a dependency. If Redis goes down, your site slows to a crawl—or breaks entirely, depending on how your host configured the fallback. Managed WordPress hosts like BigScoots typically handle this gracefully, but if you’re self-managing a VPS, you need monitoring in place.
You also need to flush the cache deliberately when you update content. Most caching plugins handle this automatically, but edge cases exist: custom fields updated via WP-CLI, direct database edits, or theme changes can leave stale data in Redis for hours.
Skip object caching if:
- Your traffic is under 10,000 page views per month
- Your average page load is already under 1 second (check your server response time in Google Search Console or Pingdom)
- You’re running a static site generator or headless setup (the database isn’t the bottleneck)
In those scenarios, you’ll get more value from a CDN, image optimization, or trimming down plugins. Object caching is overkill.
How to set it up (if you need it)
Most managed WordPress hosts offer Redis or Memcached as a one-click add-on. If you’re on a VPS, you’ll need to install Redis via SSH, then add a PHP extension and a WordPress plugin to connect the two.
The most common plugin is Redis Object Cache by Till Krüss. It’s free, actively maintained, and shows you cache hits versus misses in the WordPress admin. If your hit rate is below 80%, something’s misconfigured—either the cache isn’t being populated correctly, or your queries aren’t cacheable.
After enabling object caching, test these scenarios:
- Load your homepage twice in quick succession. The second load should be faster.
- Publish a new post and confirm it appears immediately (not after a manual cache flush).
- Check your server’s memory usage. Redis should sit around 50–100 MB for a typical site. If it’s ballooning past 500 MB, your cache isn’t expiring old data.
One non-obvious tip
Not all database queries should be cached. User-specific data—cart contents, login states, personalized recommendations—needs to stay dynamic. If you cache those, you’ll serve the wrong content to the wrong people.
Most caching plugins exclude these by default, but custom plugins don’t always play nice. If you’re seeing logged-in users get logged-out views, or vice versa, check your cache exclusions. You may need to add specific query keys or user roles to a denylist.
The other gotcha: WordPress transients. These are temporary database entries that plugins use to store short-lived data—API responses, rate-limit counters, import progress. If your object cache is working, transients get stored in Redis instead of MySQL. That’s faster, but it also means transients disappear when you flush the cache. If a plugin relies on a transient sticking around, flushing can break it mid-operation.
Check your transient usage with a plugin like Transients Manager. If you see hundreds of expired transients piling up, something’s writing to the cache inefficiently.
Want more infrastructure breakdowns like this? Reply and tell us what hosting or performance topic to tackle next—or subscribe to catch every Tuesday tutorial.