If you’ve spent any time trying to speed up a WordPress site, you’ve run into three terms that get thrown around as if they’re interchangeable: page cache, object cache, and CDN. They are not the same thing. Understanding page cache vs object cache vs CDN is the single fastest way to stop wasting money on tools you don’t need and start fixing the bottleneck you actually have.
The short version: each one caches a different thing, at a different stage of the request, to solve a different problem. A page cache stores finished HTML. An object cache stores the results of database queries. A CDN stores your files close to your visitors. The fastest WordPress sites use all three together, because they overlap far less than people assume.
This guide breaks down what each layer does in plain English, when you genuinely need it, and how they stack. No jargon walls, no invented benchmarks.
What a page cache actually does
Every time WordPress serves a page, PHP boots up, loads plugins and your theme, runs dozens of database queries, and assembles a finished HTML document. That’s a lot of work to repeat for every single visitor — especially when the result is identical for most of them.
A page cache (also called full-page caching) saves that finished HTML the first time it’s built, then serves the saved copy to the next visitor without running PHP or touching the database at all. The response goes from “hundreds of milliseconds of PHP work” to “read a file and send it.”
Good WordPress page caches serve that HTML before WordPress even boots — Speed of Light does this with an advanced-cache.php drop-in that intercepts the request early. The difference between a cached and uncached page load is usually the biggest single speed win most sites will ever get.
When you need it: almost always. If your site has any meaningful traffic and pages that look the same to most anonymous visitors — blogs, brochure sites, most WooCommerce catalog pages — page caching is non-negotiable.
The important caveat: page caching is for anonymous visitors. Logged-in users, shopping carts, and checkout pages must bypass the cache, or people will see each other’s data. Any caching plugin worth using handles this automatically. If you run a store, see our guide on how to speed up WooCommerce without breaking checkout for the details that matter.
What an object cache actually does
Here’s where the page cache vs object cache distinction trips people up. If a page cache already skips the database by serving finished HTML, why would you need an object cache too?
Because the page cache only helps on cache hits. Every time a page has to be built fresh — a cache miss, an expired entry, a logged-in user, an admin screen, an AJAX request, a WP-CLI task, a cron job — WordPress runs all those database queries again. An object cache speeds up that work.
An object cache stores the results of individual database queries and computed values in fast memory (usually Redis or Memcached). WordPress has an in-memory object cache built in, but it’s discarded at the end of every request. A persistent object cache keeps those results across requests. So the second time WordPress needs “the list of active plugins” or “this user’s meta” or the output of an expensive query, it reads it from memory in microseconds instead of hitting the database.
When you need it: dynamic, query-heavy sites. WooCommerce stores, membership sites, large forums, sites with lots of logged-in users, and anything with a busy admin. On a small, mostly-static blog where the page cache handles 95% of traffic, an object cache adds less. On a store where every logged-in shopper and every cart update runs uncached, it can be transformative. We go deeper in what is a Redis object cache in WordPress.
The catch: an object cache needs Redis or Memcached running on your server, plus a drop-in to connect WordPress to it. This is where a lot of plugins tap out — most don’t include one at all.
What a CDN actually does
A CDN (content delivery network) is a global network of servers that store copies of your files and serve them from a location physically near each visitor. Instead of everyone downloading your images, CSS, and JavaScript from your one origin server, they get them from a nearby edge node.
This matters for two reasons. First, distance is latency — a visitor in Sydney fetching files from a server in Frankfurt waits noticeably longer than one fetching from a Sydney edge. Second, offloading static files takes load off your origin so it can focus on the dynamic work only it can do.
There’s an important nuance here. A traditional CDN caches static assets (images, fonts, CSS, JS). Edge page caching goes further and caches the full HTML page at the CDN’s edge — so the request never even reaches your origin server. Cloudflare’s free plan can do full-page edge caching for WordPress through modern Cache Rules, and it’s one of the most underrated free speed wins available. We walk through it in full-page caching on Cloudflare’s free plan.
When you need it: whenever you have visitors outside your server’s region, image-heavy pages, or traffic spikes. For a strictly local audience on a well-located server, the gains are smaller — but the edge-caching layer still helps absorb bursts.
Page cache vs object cache vs CDN: side by side
The cleanest way to hold the difference in your head is to ask what each layer caches and where it lives:
| Page cache | Object cache | CDN | |
|---|---|---|---|
| Caches what | Finished HTML pages | Database query results & computed values | Static files (and optionally full HTML at the edge) |
| Lives where | Your server (disk) or CDN edge | Your server’s memory (Redis/Memcached) | Global edge network |
| Skips | PHP + the whole WordPress boot | The database round-trip | The trip to your origin server |
| Helps most | Anonymous page views | Dynamic / logged-in / admin / cron work | Global visitors & asset delivery |
| Needs | A caching plugin | Redis or Memcached + a drop-in | A CDN account (Cloudflare, etc.) |
Notice that they barely overlap. That’s the whole point. They aren’t competitors — they’re a stack.
How the three layers work together
Picture a single request from a visitor in another country, walking outward from your database toward their browser:
- CDN edge cache — If the full HTML is cached at the nearest edge node, the visitor gets it instantly and the request never touches your server. Done.
- Origin page cache — If the edge doesn’t have it, the request reaches your server, where the disk page cache serves saved HTML without booting WordPress.
- Object cache — If the page has to be built fresh (a miss, a logged-in user, an admin action), the object cache serves query results from memory so PHP does far less work.
- The database — Only reached when nothing above it has the answer.
Each layer catches what the one before it missed. The CDN handles geography and spikes, the page cache handles repeat anonymous views, and the object cache handles everything dynamic that can’t be page-cached. Remove any one and you leave a class of requests running slow.
Worth saying plainly: caching is only half of a fast site. It reduces server time, but your Core Web Vitals also depend on front-end work — trimming unused CSS, deferring unused JavaScript, and serving modern image formats. A complete speed setup pairs all three caching layers with real front-end optimization.
Do you have to buy three separate tools?
This is the part that quietly costs people the most money. Historically, yes — you’d buy a page-caching plugin, then a separate object-cache solution, then a CDN subscription, then an image-optimization add-on on top.
Most popular caching plugins still work this way. WP Rocket has a strong page cache but no built-in object cache, its image optimization is a separate paid add-on, and its CDN is a separate subscription. FlyingPress is excellent at CSS and images but has no Redis object cache. LiteSpeed Cache includes an object cache but needs a LiteSpeed server for full strength, and its images/CDN run through a metered cloud service. Among the well-known options, only LiteSpeed Cache and W3 Total Cache include a built-in object cache at all.
| Plugin | Page cache | Built-in object cache | Edge / full-page CDN caching | Image optimization included |
|---|---|---|---|---|
| Speed of Light | Yes (disk) | Yes (Redis) | Yes (Cloudflare free-plan Cache Rules) | Yes (on your own server) |
| WP Rocket | Yes | No | Needs Cloudflare APO | Add-on (Imagify) |
| FlyingPress | Yes | No | Via FlyingCDN | Yes |
| LiteSpeed Cache | Yes (LiteSpeed server) | Yes | Via QUIC.cloud (metered) | Via QUIC.cloud (metered) |
| W3 Total Cache | Yes | Yes | Many CDNs (manual) | Limited |
This is exactly where Speed of Light is built differently. All three caching layers come in one license: a disk full-page cache served before WordPress boots, full-page Cloudflare edge caching that works on the free Cloudflare plan through modern Cache Rules (no Page Rules used), and a native Redis object-cache drop-in with a real GUI and value compression. Image optimization — WebP by default plus AVIF, converted on your own server — Critical CSS, JavaScript delay/defer, self-hosted Google Fonts, and Core Web Vitals tuning are included too. No object-cache add-on, no metered image service, no separate CDN subscription.
For a broader look at how the field stacks up, see our ranked list of the best WordPress caching plugins in 2026 and the head-to-head WP Rocket vs LiteSpeed vs FlyingPress comparison.
Frequently asked questions
Do I really need all three, or is a page cache enough?
For a small, mostly-static blog, a good page cache plus a CDN covers most of the win, and an object cache adds less. But the moment your site is dynamic — a store, a membership site, lots of logged-in users, a busy admin — the object cache starts handling all the traffic the page cache can’t. Fast, dynamic sites genuinely benefit from all three.
Is a CDN the same as edge caching?
Not quite. A traditional CDN caches your static files (images, CSS, JS) near visitors. Edge page caching goes further and caches the full HTML at the CDN’s edge, so the request never reaches your origin at all. Cloudflare’s free plan can do full-page edge caching for WordPress via Cache Rules — a genuine speed layer, not just asset delivery.
Will an object cache speed up a page my page cache already serves?
No — and that’s fine. When the page cache scores a hit, WordPress never runs, so there are no queries for the object cache to accelerate. The object cache pays off on everything the page cache can’t serve: cache misses, logged-in users, admin screens, AJAX, and cron. The two are complementary, not redundant.
Can too much caching break my site?
The main risk is caching content that should stay dynamic — serving a logged-in user’s data to everyone, or caching a live shopping cart. That’s why proper WordPress caching is anonymous-only and always bypasses carts and checkout. Use a tool that handles those exclusions automatically rather than hand-rolling cache rules.
Does an object cache require a special server?
It needs Redis or Memcached available on your host, plus a drop-in to connect WordPress to it. Many managed and VPS hosts offer Redis; some shared plans don’t. If yours does, a plugin with a built-in Redis object cache lets you turn it on without wiring anything up by hand.
The bottom line
Page cache vs object cache vs CDN isn’t a choice between three options — it’s three jobs. The page cache skips PHP for anonymous visitors, the object cache skips the database for everything dynamic, and the CDN skips the distance to your visitors. Stack them and every kind of request gets faster.
If you’d rather have all three layers plus image optimization and Core Web Vitals tuning in a single license — with a Redis object cache and free-plan Cloudflare edge caching that most plugins make you buy separately — take a look at Speed of Light. It’s an all-in-one WordPress speed engine, backed by a 14-day money-back guarantee.
