WordPress Caching Explained: Edge, Page, Object, and When Each One Saves You

“Just add a caching plugin” is the most common WordPress performance advice — and the most incomplete. Caching isn’t one thing; it’s a stack of layers that each solve a different problem. Understanding where each layer sits explains why some sites fly and others stay slow no matter how many plugins they install.

The four layers

1. Edge / CDN cache

The layer closest to your visitor. Static assets — images, CSS, JavaScript, fonts — are served from a point of presence near the user, so a visitor in Singapore isn’t fetching your hero image from a server in Frankfurt. For most sites this is 70–90% of bytes transferred.

Where it fails: it can’t help with HTML unless you cache full pages at the edge, and doing that naively breaks anything personalized.

2. Full-page cache

The biggest single win for WordPress. Instead of running PHP and querying the database for every request, the generated HTML is stored and re-served. A page-cache hit is typically 10–50x faster than a WordPress render and costs almost no CPU.

Where it fails: logged-in users, carts, and any page with per-visitor content must bypass it. The quality of a page-cache setup is really the quality of its bypass and invalidation rules — stale product prices are worse than slow product pages.

3. Object cache

WordPress internally caches query results and computed values. By default that cache lives only for a single request — which is nearly useless. A persistent object cache (Redis or similar) shares it across requests, so expensive queries (option lookups, term trees, WooCommerce sessions) are answered from memory.

Where it saves you: exactly the pages that bypass full-page cache. A logged-in WooCommerce checkout can’t be page-cached, but with a warm object cache its database work drops dramatically.

4. OPcache

PHP compiles source files to bytecode before executing them. OPcache keeps that bytecode in memory so compilation happens once, not on every request. It’s invisible when configured well and devastating when absent — this is table stakes, not an optimization.

Composition is the hard part

Each layer is well understood in isolation. The engineering is in how they compose:

• Page cache invalidation must cascade: publish a post and the homepage, feeds, archive pages, and edge copies all need purging — atomically, not eventually.
• Object cache and page cache disagree about freshness unless purges are coordinated.
• Edge rules must know which routes are personalized, which vary by cookie or currency, and which are safe to hold for a week.

This coordination is why “install three caching plugins” often makes sites slower and less correct: the layers fight each other’s assumptions.

How AutoPress ships it

On AutoPress the whole stack — edge cache with WordPress-aware rules, full-page cache with cascade invalidation, persistent object cache, and tuned OPcache — is configured at the platform layer for every site. There is nothing to install and no invalidation webhooks to maintain: publishing a post purges the right pages everywhere within seconds, and WooCommerce routes bypass exactly what they should.

The result is the boring ideal: cache behavior you never think about, hit ratios you don’t have to tune, and origin servers that only work when there’s real work to do. If you want to see your own site’s cache profile, migrate a copy into staging — the dashboard shows hit ratios per layer out of the box.