He explained object caching like this:
When you think about page caching, we take all the stuff on the front end and flatten it into one HTML file, and that speeds up the site. This is not that kind of caching. This is PHP object caching. It goes out and grabs some stuff out of the database, and it holds that as an object. Or if the server has to calculate something to give to the front end, it holds that as an object too.
That’s a more technical explanation, but it draws a great contrast between page and object caching:
Page caching: Saves a complete, ready-to-serve copy of a page then serves it to every visitor. It only works for pages that look the same for everyone, though, so nothing logged-in, personalized, or dynamic.
Object caching: Consequently, saves things page caching can’t. While those pages still have to be rebuilt from scratch, all the database results and calculations come from the cache, removing the need to start from zero on every request.
As you can see, it’s a rather noticable difference, but there is something we want to further clarify. We’ve mentioned “dynamic” and “static” a few times now, and in our experience we’ve noticed that the meanings of those words can be misinterpreted.
When talking about “dynamic” and “static” it’s easy to assume they relate to whether or not something moves on the page, like a rotating carousel of images or a hover effect. It’s a logical assumption, but not the correct one when it comes to caching. In caching, “dynamic” and “static” refer to content that changed depending on who is viewing or when they are viewing.
Yes, a carousel of images looks dynamic, but from a caching standpoint it’s a static part of the website; it looks the same for everyone. On the other hand, a “Welcome back <name>!” greeting, cart contents, or live inventory counts are dynamic, because the server has to compute something different for each visitor.
That’s a vital distinction and it determines if page caching can handle something on its own or object caching needs to help build it. That’s why sites that rely solely on page caching still feel slow in those areas.
Non-persistent and persistent object caching: a critical difference
While we are on the topic of distinctions, let’s spotlight another one.
Did you know WordPress already has built-in object caching? It’s active by default, but the catch is it’s “non-persistent.” It only lasts for the length of a single page load and then gets wiped. The next visitor, or even the next page you go to, starts from zero again.
That raises a fair question: if it gets wiped so quickly, what’s the point? A “single page load” isn’t just the page appearing on your screen. It actually involves dozens, sometimes hundreds, of queries to the database to assemble a page. It’s common for the same piece of information to be requested multiple times. Non-persistent caching saves those repeats in memory so that anything else that needs them gets a copy of what’s already on hand.
On the other hand, persistent object caching works on a bigger scale. Instead of clearing after each page load, it stays alive between requests and users. The next visitor benefits from the same cache all previous ones have.
We put together this table below that cleanly showcases the distinction.
| Non-persistent | Persistent |
Lifespan | Wiped once all the database queries are done and the page is built. | Remains between requests and even users. |
What it speeds up | Repeat database calls within the same page building process. | Repeat database calls across every visit to the page. |
Who benefits | Only the one page load that’s in progress. | Every future visitor and page load. |
Setup required | WordPress has it on by default, similar to how other platforms handle it. | Needs a specific technology (Redis or Memcached) and activation. |
In short, non-persistent caching is WordPress being efficient with itself, while persistent caching is what turns that efficiency into something your whole site and every visitor can benefit from. That’s also the upgrade the Site Health warning is pointing you toward.
Signs your site is ready for object caching
You might think, since persistent object caching does so much, you need it from day one. That can be true for some sites, but it doesn’t apply to every website. Mostly static sites (brochure or portfolio sites) don’t necessarily need it. It’s a moving part that won’t offer much benefit, since those don’t often have many repeating database queries.
Additionally, not all hosting can handle object caching efficiently. Redis, which we’ll talk about in a bit, uses server memory, so small plans or VPS with tight resource limits might struggle (if object caching is even possible to enable there).
As to what to watch out for, here’s some signals that might indicate your site needs persistent object caching.
Read-heavy traffic: Visitors mostly look things up on your website, like products, listings, profiles, etc. A prime example is online stores, where data flows from the database to the user through repeated queries.
As you can see, many of these have to do with your site slowing down. That’s the core of the situation here and we’ve covered that in more general terms on our blog. If your site is not as fast as it was before and the only thing has changed is user numbers, then it might be time to look into object caching.
Redis or Memcached?
If you’ve ever researched object caching, you’ll run into two names: Redis and Memcached. They are both technologies for object caching but do it slightly differently. Our advice for 2026 and WordPress is Redis, but there is a caveat.
Yes, Redis does more. It supports more data types and handles cache invalidation more gracefully. The tradeoff is that it uses server memory, so it’s not the “lighter option.” Memcached is simpler and leaner by design and on plans or servers with limited resources, that can matter a lot. It’s the better choice for that specific situation.
For most sites, WordPress included, on reasonably resourced hosting, though, the extra features and ecosystem support Redis offers outweigh the difference in overhead. That’s also why it’s become the default for the majority of websites.
How to enable object caching on your website
Finally, let’s round out this blog post with showing you how to take advantage of object caching. To start, you should check if your hosting has it available. Your host plays a big part in how fast your site is, which includes access to Redis, and Nathan agrees:
If you're on a good server, you ought to have access to Redis or Memcached as an object cache, and you probably ought to use it.
Because of its resource needs, Redis tends to appear more commonly in VPS or dedicated server environments. Check if your hosting plan has it before looking for upgrades or a new optimization plugin.
For the Managed hosting for WordPress here on hosting.com, object cache is enabled by default on our Medium, Advanced, and Turbo plans. They also include Object Cache Pro and WP Rocket which will take care of all your site’s caching (page and object) without you ever having to lift a finger.
How to confirm object cache is working
Looking up how to check if object cache is working, you might come across advice that requires you to run commands in command line or use specific code snippets. If you are on WordPress, though, there is a much easier way.
There are many plugins that do this, but Query Monitor is our recommendation. It’s a straightforward plugin that shows you when data is served from the database or the cache. Simple as that. You don’t need any coding or technical experience to understand it. Load a few pages, get the cache rolling, and watch for the cache hits: that means it’s working.
What improvements to expect
As with all other optimization techniques, persistent object cache isn’t a magic bullet so it’s vital to set your expectations accordingly.
The area it will make the most significant impact is in your site’s dynamic pages. Things like your site’s admin dashboard should feel snappier, store catalogs should hold up better under logged-in traffic, and TTFB on those dynamic pages should return to reasonable values and stay there.
During the Office Hours livestream, Nathan explained it very well:
We notice a real speed increase in the WordPress backend, especially with WooCommerce sites. When you go to a page of WooCommerce analytics and it's got all this number crunching to do, it'll save that stuff in an object cache and pull that.
On the other hand, if your site is mostly static, you will likely not notice much improvement. That’s expected, though, since object caching is built for sites that are growing and isn’t necessary on every site by default.
There is one more expectation that we need to set, though. It’s more of a heads-up, actually. Cache can get stale, meaning when you update something your site might still serve old content from the cache. Many plugins refresh their cache when any changes to content or the database occur (such as Object Cache Pro and WP Rocket on our hosting plans), but it’s still good to keep that caveat in mind.
While you are at it
Object caching is just one piece of a bigger performance picture. It will help your site’s dynamic pages be more efficient, but it won’t touch any static pages, nor will it help with other factors that can negatively impact site loading speed.
That’s why having a broader view on speed optimization is vital for growing websites. Most of them eventually hit a point where page caching isn’t enough. Then object caching has fulfilled its purpose, so it’s time for the next step, then the next one, and the next one. For most websites, caching is the first few steps, and they are absolutely worth taking.
FAQ
Does object caching directly improve my SEO?
Not directly, but it supports it indirectly. Google's Core Web Vitals mostly measure what a visitor's browser experiences (loading, interactivity, visual stability), and those are more directly influenced by page caching and front-end assets. Object caching helps by keeping your server responsive under load and speeding up dynamic pages, which prevents the kind of slowdowns that eventually do hurt Core Web Vitals scores, especially as traffic grows.
How is object caching different from OPcache?
They solve different problems. OPcache stores pre-compiled PHP code so the server doesn't have to recompile the same PHP files on every request. Object caching stores the results of database queries and calculations, not the code itself. Most well-configured hosting environments run both at once, since they speed up different parts of the request process rather than competing with each other.
Can turning on persistent object caching break my site?
It's rare, but not impossible. The most common issue isn't breakage, it's a poorly coded plugin that doesn't properly clear its own cached data after an update, which can cause stale content to show up longer than expected. This is uncommon with well-maintained plugins and managed setups like Object Cache Pro, but it's worth testing your key plugins after activation rather than assuming everything will behave immediately.
Does every plugin automatically benefit from object caching once it's turned on?
Not entirely. Plugins benefit automatically for the database queries WordPress core handles on their behalf, but a plugin only gets the full advantage if its developer specifically wrote it to use WordPress's object cache functions. Most modern, well-maintained plugins do this, but it's part of why results can vary slightly from site to site depending on which plugins you're running.