Object caching, and when a content network does not need it

Object caching stores the results of individual database queries so the application does not repeat them. It sits underneath page caching and solves a different problem, which is why turning it on rarely helps a site that is already serving cached pages well.

Two caches, two jobs

• Page cache: stores the finished HTML. On a hit, nothing runs. This is where almost all of the benefit is for a content site.
• Object cache: stores query results inside the application. It only helps when the application is running, which by definition is when the page cache missed.

So object caching improves the requests that page caching could not eliminate. If 95 percent of your requests are page cache hits, object caching is optimising the remaining 5 percent.

When it earns its place

It is worth having when a meaningful share of your traffic cannot be page cached:

• A shop, where carts, checkout and account pages are personalised by nature.
• A membership site where most visitors are logged in.
• A site with heavy filtering or search, where every combination is a distinct page.
• A very large site where the admin interface itself is slow, since the dashboard is never page cached.

The pattern is consistent: object caching helps when logged in or personalised traffic is a large fraction of the whole.

When it is not worth the moving part

For a network of editorial sites with mostly anonymous readers, page caching already removes the work. Adding a persistent object cache to each of thirty sites adds thirty things that can hold stale data, thirty things to purge during an incident, and memory consumption on an account that has a ceiling.

That last cost is easy to overlook. A persistent object cache holds data in memory, and memory is one of the limits your account runs inside. Spending it on a cache that serves a small slice of requests is a poor trade when the same memory keeps ordinary requests from being killed. See Platform and Limits for what that ceiling governs.

The failure mode to know about

Stale object data is more confusing than stale pages. A stale page is obvious: you look at it and it is old. Stale objects produce partial staleness, where a page is fresh but one widget inside it is not, or a setting appears to have saved but does not take effect. Debugging that costs more time than the milliseconds saved on a site that did not need it.

If you enable it, make purging it part of your deployment routine rather than something you remember to do after being confused.

A reasonable position

1. Get page caching right on every site first, and verify it is actually filling.
2. Measure what fraction of your requests still reach the application. If it is small, stop here.
3. Enable object caching only on the specific sites where personalised traffic is significant, not across the network by default.
4. Keep a note of which sites have it, so the next person debugging one of them knows.

This is the same discipline as everything else on a multi-site network: apply the thing that helps where it helps, rather than applying it everywhere because it helped once. Configuration consistency is covered in Speed and Caching.

WordPress documents the caching layers at developer.wordpress.org. If a site genuinely needs persistent services beyond what a shared account provides, that is one of the honest reasons to look at a VPS with root access.