Managing your site

How caching works: page cache, object cache, Clear cache

Your site sits behind two independent caches — a full-page cache at our edge that answers most visitors without ever waking PHP, and a private Redis object cache that makes the requests which can't be page-cached cheaper. Both are on by default, with no plugin to install and nothing to tune.

The page cache is first-party: it runs in our own edge in front of your site, not as a plugin inside WordPress. That's why there's nothing for you to install, configure or accidentally break — and why a caching plugin is usually the wrong thing to add here. A cached page comes back in about 5ms and never reaches PHP or your database. Your static files are a separate story: images, CSS and JavaScript are cached on Cloudflare's global network and served from the point of presence nearest each visitor, which is why assets stay fast for an audience on the other side of the world even though your HTML is served from the node your site runs on.

The object cache is a Redis instance that belongs to your site alone: its own container on your site's own private network. It holds the database work WordPress repeats on every request, so the pages a page cache can never serve — logged-in visitors, cart, checkout, account pages — still do far less work. Two properties matter. It's isolated: another site clearing its cache cannot reach your keys, because the network is the boundary rather than a shared password or a key prefix. And it's fail-open: if the cache is ever unreachable, WordPress falls back to its own built-in caching and your site keeps serving, just slower. A cache problem can't take your site down.

Publish normally — we clear for you
Editing or publishing a post clears the pages that changed. Most of the time you never need to think about the cache at all.
Clear cache clears both layers
The Clear cache button on the site's Overview empties the page cache and the object cache together. Reach for it after a change that touches the whole site — a theme switch, a plugin update, a bulk edit.
Purge one URL
Purge a specific URL drops a single page from the page cache while the rest stays warm — handy after fixing a typo on one page. It doesn't touch the object cache.

What is never served from the page cache

wp-admin, login and the REST API; the standard /cart, /checkout and /my-account paths; and any visitor already carrying a login or WooCommerce cart cookie, who is always served live. On top of that, any front-end response that sets a cookie is marked private at the origin, so a session can never be stored and handed to the next visitor. If your store uses custom or translated cart and checkout URLs, tell us and we'll add them to the bypass list.

A low hit-ratio isn't a problem to fix

The Analytics tab shows the share of traffic served from the page cache. A busy store sits much lower than a brochure site, because carts, checkout and logged-in sessions are supposed to miss. There's no number to chase — the object cache is what makes those misses cheap.

← All guides