WordPress caching works best when you stop treating it as a single switch. A fast site usually relies on three different layers: page cache, object cache, and a CDN. They solve different delays, they live in different places, and they fail in different ways.
That distinction matters. Many site owners enable one cache plugin, see a speed bump, and assume the job is done. Then traffic rises, logged-in users slow down, or database-heavy pages still drag. The problem is not that caching failed. The problem is that the wrong layer was asked to do all the work.
What each cache layer actually does
Page cache stores the finished HTML of a page so WordPress does not have to rebuild it on every visit. Object cache stores repeated database query results and computed PHP objects so the application can reuse them. A CDN stores static assets, and sometimes full responses, on edge servers closer to visitors.
Those three layers sit on different parts of the request path. Page cache reduces PHP work. Object cache reduces database work. A CDN reduces network distance and origin load. Since each one cuts a different cost, they are not rivals. They are stacked helpers.
Page cache
When an anonymous visitor opens a normal WordPress page, WordPress usually has to load PHP, run plugins, query the database, build the template, and return HTML. Page cache short-circuits that process by serving a saved HTML copy.
This is why page cache often produces the most visible jump first. On brochure sites, blogs, magazine pages, landing pages, and documentation pages, the HTML output changes far less often than people assume.
Best use cases
Page cache fits public pages with repeated traffic: homepages, article pages, category archives, evergreen guides, and most marketing pages. It also helps during traffic spikes because the server can serve cached HTML instead of rebuilding each request.
Where page cache gets tricky
It can break when the page is highly personalized. Cart pages, checkout, account dashboards, membership content, and some multilingual or geolocation setups need careful exclusion rules. Over time, cookie-based variations, query strings, and device-based output can create stale or wrong cache versions if the setup is careless.
What it does not fix
Page cache does not improve the editing experience in wp-admin. It also does little for requests that bypass the cached HTML, such as many logged-in sessions, uncached AJAX calls, or custom API logic.
Object cache
WordPress already has an internal object cache during a single request. The real gain starts when that cache becomes persistent, usually through Redis or Memcached. Then repeated query results and data objects can survive between requests.
This layer matters most on sites where the bottleneck is not template rendering but repeated database work. Think WooCommerce stores with filters, membership sites, large menus, heavy custom fields, busy search pages, or plugin stacks that ask the database the same questions again and again.
Best use cases
Object cache helps when the same fragments are rebuilt often: option lookups, product data, taxonomy trees, user-related data, and custom query results. Since its effect is closer to the application layer, it often helps both front-end requests and some back-end actions.
Where object cache gets tricky
It needs correct invalidation. If cached objects are not cleared when content changes, old data lingers. That can show up as stale prices, outdated stock levels, old menus, or missing edits. Page cache serves stale pages; object cache serves stale logic. The symptom feels different, and so does the fix.
What it does not fix
Object cache does not replace page cache. It still leaves PHP running and templates rendering. On a simple blog with light plugins, the gains may be modest because the database was never the slowest part.
CDN
A CDN places copies of assets on edge servers in many regions. Images, CSS, JavaScript, fonts, and downloads can be delivered from a location nearer to the visitor. Some CDN setups also cache whole HTML responses at the edge.
For global traffic, this changes the feel of a site more than many site owners expect. The origin server may be in one country, but users are not. Every extra round trip adds delay. A CDN cuts that distance and absorbs bursts that would otherwise hit the origin directly.
Best use cases
CDNs fit image-heavy sites, global audiences, media libraries, theme assets, script-heavy front ends, and campaigns that may see sudden traffic. They also pair well with image optimization, compression, and edge caching rules.
Where CDN setup gets tricky
Problems usually come from cache headers, purging rules, and asset versioning. If old CSS or JavaScript remains at the edge after deployment, users can see broken layouts or scripts. Over time, aggressive edge caching without a purge plan becomes a maintenance problem, not a speed win.
What it does not fix
A CDN cannot hide a slow origin forever. If the HTML is generated slowly, database queries are heavy, or plugins are wasteful, the origin still needs work. The CDN helps with delivery; it does not rewrite inefficient application behavior.
Page cache vs object cache vs CDN
| Layer | Caches | Main benefit | Best for | Common risk |
|---|---|---|---|---|
| Page Cache | Rendered HTML pages | Reduces PHP execution and repeated page generation | Public pages, blogs, landing pages, archives | Serving stale or wrong page variants |
| Object Cache | Database query results and PHP objects | Reduces repeated database work | WooCommerce, memberships, complex plugins, custom queries | Stale data due to weak invalidation |
| CDN | Static assets and sometimes full responses | Reduces latency and origin load | Global traffic, media-heavy pages, asset delivery | Old assets at the edge after updates |
How these layers work together on a real request
The cleanest path is simple. A visitor requests a page. If edge HTML caching exists, the CDN may answer first. If not, the request reaches the origin. Then page cache may serve saved HTML. If page cache misses, WordPress runs. During that build process, object cache may supply stored query results instead of asking the database again. The finished response can then be cached for later requests.
That order explains why page cache and object cache can both be active without overlap. One avoids page generation. The other makes page generation cheaper when it still has to happen.
Which layer should you enable first
For a typical content site
Start with page cache. It usually brings the clearest gain for anonymous traffic. Add a CDN next if the audience is international or the site carries many images and static files.
For WooCommerce or dynamic membership sites
Use page cache carefully, excluding cart, checkout, account, and other personalized areas. Then add persistent object cache. On stores and application-style sites, that second layer often matters more than people expect.
For global audiences
A CDN moves up the list quickly. Even a well-optimized origin feels slow when users are far away. Edge delivery changes that basic geography problem.
Common mistakes
Using page cache without exclusions
Cached carts, cached account pages, and cached language variants still show up on live sites. The setup looks fast in testing, then fails under real sessions.
Adding Redis and expecting every page to become fast
Persistent object cache helps database-heavy sites. It is not magic for a light brochure site with little query pressure.
Ignoring cache purges after deployments
New CSS, old JavaScript, edge-cached HTML, and browser cache can conflict. Versioned assets and a predictable purge routine keep releases cleaner.
Measuring only one page while logged out
A homepage test can look perfect while product filters, search, logged-in sessions, or admin actions remain slow. Cache wins should be measured on the page types that actually hurt.
What to measure after setup
Check TTFB, full load behavior, server CPU spikes, database load, cache hit rates, and the experience of uncached page types. On WordPress sites with mixed traffic, it is also worth testing logged-in and logged-out users separately.
If page cache is doing its job, anonymous HTML pages should become much cheaper to serve. If object cache is working, repeated dynamic requests should hit the database less often. If the CDN is set well, far-away visitors should see faster asset delivery and less origin strain during busy periods.
A practical rule of thumb
Page cache is the first line for public HTML. Object cache is the pressure relief valve for repeated application queries. CDN is the delivery layer that shortens distance and absorbs edge traffic. Since each layer removes a different kind of waste, the fastest WordPress setups rarely pick one of them in isolation; they use the right mix for the way the site actually behaves.
References
- WordPress Developer Resources – Cache (Official WordPress documentation on cache behavior, including object caching concepts and performance notes.)
- MDN Web Docs – CDN (A direct explanation of content delivery networks and how edge delivery reduces latency.)
