WordPress Caching Explained: What Each Layer Actually Does
Most people switch on a caching plugin, tick a few boxes, and assume the job is done. Sometimes that is enough. More often, it is just the surface layer of a much deeper system, and the layers underneath are either misconfigured or missing entirely. Understanding what caching actually does at each level makes the difference between a site that feels fast and one that is fast, measurably, every time a real visitor lands on it.
On this page
Why Caching Exists at All
WordPress is a dynamic system. Without caching, every page request triggers a chain of events: PHP runs, queries hit the database, the result gets assembled, and the HTML is sent to the browser. On a quiet site with a small database, that might take 300 milliseconds. On a busier site, or one with a bloated theme and thirty active plugins, you can be looking at over two seconds per request before the browser has even started loading anything.
Caching breaks that chain by storing the finished result and serving it directly on the next request. The principle is simple. The implementation has several distinct layers, and each one solves a different part of the problem.
Browser Caching: The Layer Closest to the Visitor
When someone visits your site, their browser downloads assets, images, stylesheets, scripts, fonts. Browser caching tells the browser how long to keep those files before requesting fresh copies. This is controlled through HTTP headers, specifically Cache-Control and Expires.
A well-configured server sets long cache lifetimes on assets that rarely change, such as a logo or a font file, and shorter lifetimes on things that update frequently. Get this wrong and visitors re-download the same 200kb image on every page load. Get it right and returning visitors experience near-instant load times because most of the page is already sitting on their device.
This layer is free to implement and has a direct effect on Core Web Vitals scores, particularly Largest Contentful Paint for returning visitors. It is also one of the first things Google’s PageSpeed Insights flags when it is missing.
Page Caching: Where Most Plugins Start
Page caching is what most WordPress caching plugins actually provide. The first time a page is requested, WordPress builds the full HTML output. The plugin saves that HTML to disk or memory. Every subsequent request gets the saved copy, skipping PHP and the database entirely.
This is the biggest single performance win available to a typical WordPress site. A page that previously took 900ms to generate can serve in under 50ms from a warm cache. The difference is that dramatic.
There is a caveat worth knowing. Page caching and dynamic content do not always mix well. Cart pages, checkout flows, and anything personalised per user cannot be cached generically. A good caching setup excludes those URLs explicitly. Miss that step and you end up with customers seeing each other’s session data, which is a serious problem beyond just performance.
Object Caching: Saving Database Work Between Requests
WordPress has a built-in object cache, but by default it only lasts for the duration of a single request. Once the page is delivered, everything it stored is discarded. A persistent object cache changes that. Tools like Redis or Memcached keep frequently used database query results in memory across requests.
This matters most on sites where page caching cannot cover everything. A membership site, a WooCommerce store with complex filtering, or a site running lots of shortcodes that hit the database on every load, all of these benefit from object caching in a way that page caching alone cannot address. Most small business sites never need it. Larger, data-heavy ones often cannot perform well without it.
We’d argue WordPress is the most flexible website creation system ever built, powering well over 40% of the internet, and object caching is one of the features that makes serious WordPress deployments genuinely competitive with bespoke-coded alternatives.
Opcode Caching: PHP Doing Less Work
Every time PHP runs, it compiles your code from plain text into something the server can execute. Opcode caching stores that compiled version in memory so it does not need to be recompiled on the next request. OPcache, which ships with PHP itself, handles this automatically on most modern hosting.
You rarely configure this yourself. What you can check is whether it is actually enabled. A quick look at your server’s PHP info page will confirm it. If it is off, or if the allocated memory is too low, PHP is doing unnecessary work on every single request.
CDN Caching: Putting Static Files Closer to the Visitor
A content delivery network stores copies of your static assets across servers in multiple locations around the world. A visitor in Sydney pulling a file from a server in London adds latency. The same file pulled from a Sydney CDN node does not.
CDN caching works alongside your other cache layers, not instead of them. It is not a replacement for proper page caching or object caching. Think of it as the final step that reduces physical distance from file to browser. For sites with an audience across multiple countries, it is worth doing. For a purely local audience, it is a lower priority than getting the other layers right first.
If you want to understand how managed hosting stacks these layers for you automatically, that is a separate conversation worth having before you choose a host.
Getting the Stack Right
The most common mistake is treating caching as a single checkbox. Switch on a plugin, ignore the server, skip CDN setup, leave OPcache unverified. Each layer you miss is a performance gap that stays open.
- Browser cache headers should be set at the server level, not left to defaults
- Page cache exclusions need to cover every dynamic or personalised URL
- Object cache is worth adding when your site does heavy database work
- OPcache should be confirmed as active, not just assumed
- CDN is the last layer to add, once the others are solid
Done in that order, caching is not complicated. It is methodical. And a site with every layer properly configured feels genuinely different to one that just has a plugin installed and forgotten about.