WordPress caching explained: page, object, browser and CDN
Four different things share one word, which is why caching advice contradicts itself. Here is what each layer does, in what order to apply them, and what breaks.
Engineering·24 August 2026·7 min read
Ask three people how to speed up WordPress and you get three caching answers that appear to contradict each other. They usually do not. They are describing different layers that happen to share a word.
Page cache: skip the work entirely
A page cache stores the finished HTML of a page and serves that copy to the next visitor, so WordPress does not run PHP or query the database at all. It is the biggest single win available on a content site and it is why a heavy theme can still feel fast to an anonymous visitor.
Its limitation is the whole point of the other layers: it only works for pages that look the same to everyone.
Object cache: remember expensive answers
An object cache stores the results of database queries in memory so repeated requests do not re-run them. This is what helps logged in users, carts, and admin screens, none of which can use a page cache.
On a busy WooCommerce store this is often the difference between a checkout that feels instant and one that stalls under load.
Browser cache: stop re-downloading the same files
Browser caching tells the visitor's browser to keep your CSS, JavaScript, fonts and images for a period, so a second page view costs a fraction of the first.
The rule is long lifetimes for versioned assets and short ones for HTML. Get it backwards and visitors see stale pages after you publish, which is how people end up convinced caching is dangerous.
CDN: serve static things from closer, and offload the server
A content delivery network keeps copies of your static assets on servers around the world. For an audience concentrated in one country near your server, the distance gain is modest, but the offload and delivery gains are still real.
It is a good later step and a poor first one. A CDN in front of a slow page delivers a slow page faster.
The order that avoids pain
- Page cache with correct exclusions for cart, checkout, account and any logged in view.
- Browser caching with sensible lifetimes and proper versioning on assets.
- Object cache if the site has meaningful logged in or transactional traffic.
- CDN once the page itself is in decent shape.
- Re-test after each layer, not after all four, so you know which one broke something.
What breaks, and how to spot it
The two classic failures are a stale page that will not update no matter how many times you publish, and a cart that shows the wrong contents. The first is a purge configuration problem, the second is a missing exclusion and needs fixing immediately.
Always test a full purchase or enquiry flow after enabling caching, logged out and logged in. Nobody does this, and it is where the expensive surprises live.
Keeping it simple
SmartSite Optimizer applies browser caching and the asset side of this list in one pass, alongside image optimisation, minification and database cleanup, and explains what remains. For most WordPress sites that is enough, and the deeper layers only become worth configuring when there is genuine transactional traffic to protect.
Caching is four tools, not one. Match the layer to the traffic it can actually help, exclude the pages that must stay live, and test the flows that make you money before you call it done.
Frequently asked questions
Which pages should never be cached?
Cart, checkout, account pages, anything showing user specific data, and any page behind a login. Caching those either shows one customer another customer's data or silently breaks the flow. Every serious caching setup has an exclusion list, and getting it wrong on a store is the most expensive caching mistake there is.
Do I need an object cache like Redis?
Not on a small brochure site, where a page cache does nearly everything. It matters on stores and membership sites, where many requests cannot be page cached and are hitting the database repeatedly for the same values. That is exactly the traffic a page cache cannot help.
Is a CDN worth it for a Pakistan focused site?
If most of your visitors are in Pakistan and your server is too, the distance benefit is small. The delivery benefits still apply: offloading static assets, better compression and protocol support, and absorbing traffic spikes. Treat it as a useful layer rather than the first fix.