Caching comes up in every speed conversation, and the explanation usually stops at “it saves things and reuses them”. That is not wrong, but it is exactly enough knowledge to stack caches on top of each other carelessly — and that is how you end up with a page that updates for some people and not others.
The accurate model, without the jargon, is this: caching is a stack of layers, and each layer stores something different.
Three layers, three different jobs
A page cache stores the finished screen. The next visitor asking for the same page is handed the stored copy, so WordPress does no work at all. It gives the largest gain, and in exchange it cannot be used for screens that differ per person — logged-in users, baskets, anything personalised.
An object cache stores fragments rather than screens: the answer to “which category is this post in”, looked up once and reused. Because it works even when every visitor sees something different, it covers exactly the ground a page cache cannot reach — admin screens and logged-in areas.
An opcode cache sits further down again, keeping the interpreted form of the site’s program code so it is not re-read on every request. It is usually already switched on at the server, and founders rarely need to touch it.
One combination you must not stack
This is where real incidents happen: never run two page caches. If your server already caches pages and you add a caching plugin on top, two systems are storing the same screen independently.
The trouble is not the storing but the clearing. Edit a post and the plugin clears its copy, while the server’s copy knows nothing about it — so visitors keep receiving the old screen. Clear them in the other order and the old screen briefly comes back from the dead.
What makes it nasty is that most of the site looks fine. The administrator sees the updated page and only visitors are stuck on the old one, so the first report of the problem arrives from a customer.
What to do now
The sequence is simple. First establish which caches are actually on: check your hosting panel for a cache setting, and your plugin list for a caching plugin. If both are storing whole pages, switch one off — usually keep the server-side one.
Then decide where “clear the cache” lives. Knowing in advance which button to press when an edit refuses to appear removes most of the panic from that moment.
Layer configuration and invalidation rules are covered further in the performance archive, and the order in which we actually build the layers is published on our process page.
Next part
With caching sorted, everyday speed settles down. The next part is about the days that are not everyday — the minimum preparation that lets a site survive one post sending a crowd at it.