Reference guide · cloudflare · Published 2026-08-16 · 4 min read
Cloudflare Cache Reserve (HTML caching)
How to make Cloudflare cache your HTML: the default gap, a Cache Rule to the rescue, and where Cache Reserve extends persistence with its TTL and eligibility rules.
- ·The HTML gap
- ·Cache Rules for HTML
- ·Cache Reserve
The HTML gap
Cloudflare's edge does not cache HTML by default. The CDN caches static assets (CSS, JS, images, fonts) when the origin's headers allow it, but a request for your homepage goes to the origin on the first hit. Browsers cache is a different layer, and the edge cache of the HTML answer is not something you get for free until you declare it.
That is usually the right default. HTML is the dynamic layer, so caching it wholesale returns one user's cookies or personalization to another. But for a marketing page, a blog post, or an almost-statically-served homepage, the HTML is effectively static for minutes at a time, and caching it is the single biggest TTFB and origin-load win besides the images.
Cache Rules to make HTML eligible
The recommended current mechanism is a Cache Rule, which lives at Rules > Cache Rules in the dashboard. It is the replacement for the old Page Rule cache path:
- Create a rule that matches the paths you want cached.
- Set the cache eligibility to Eligible for cache.
- Decide the Edge Cache TTL. If you do not set one, Cloudflare respects the origin's
Cache-Control; set a TTL only when you want to override the origin.
if: http.request.uri.path contains "/"
action: set cache eligibility Eligible for cache
action: set edge ttl 300s
This makes the homepage cacheable at the edge. Now re-run the same logic for the rest of the site, and only for the parts that genuinely can serve one version to everyone:
| Scenario | Serve to edge cache | Keep origin-only |
|---|---|---|
| Marketing homepage, blog post | Yes | - |
| Logged-in account pages | No | Yes |
| Cart with a cookie | No | Yes |
| Static AMP / print / sitemap | Yes | - |
Cache Reserve extends the lifetime
Cache Reserve is Cloudflare's long-lived backing store, a persistent R2-backed layer above the edge cache. When Cache Reserve is enabled for a response, the edge writes the cacheable content into a durable store that does not flush every 120 minutes like the default edge TTL path. A typical result is that origin traffic collapses because a miss anywhere in the world re-feeds from the Reserve instead of from your server.
Reserve has eligibility rules:
- The asset must be cacheable by Cloudflare (your Cache Rule made HTML eligible, so that part works).
- It needs a freshness TTL of at least 10 hours, set by an origin
Cache-Control, an Edge Cache TTL,Cache TTL by status, or a Cache Rule. For pages you refresh daily, that means the TTL is deliberately long and you override change with a purge. - The origin response should carry a
Content-Lengthheader.
Reserve is a paid feature and is billed by storage and operations. Cloudflare recommends running it with Tiered Cache enabled; the two together shield the origin on a cold miss. The dashboard warns when Cache Reserve is on without Tiered Cache, because the storage cost grows for every upper-tier fetch.
The purge discipline that makes HTML caching safe
Caching HTML is a TTL game, and closing the loop with a purge is the change habit:
- Every deploy runs a POST to the
purge_cacheendpoint for the zone, using the same cache rules you just added. - For a whole-site release, a
{"purge_everything": true}is heavy but clean and fast. - For an isolated blog post that changed, one purge by URL re-fetches that page but leaves the rest of the edge alone.
- When front-end CSS or JS changes, purge those asset names too, because the browser still holds the old
.cssby its old URL.
Keep the TTL modest on pages that change often and let the edge serve old HTML where the origin is healthy. The cache purge guide has the URL and tag mechanics; the cache-control TTL article explains the header line that governs the same path.
When to leave HTML off the edge
- A site where every page is a per-user dashboard or cart.
- Pages that answer from session-specific cookies (
Cache-Control: privatealready stops the edge). - A site that is strictly static and already behind a CDN, where HTML caching adds a second invalidation surface for no benefit.
The decision point is the same for every pattern: does a stale copy of this URL cost more than a trip to the origin? When the answer is no, Cache Rules plus Cache Reserve make HTML the most cacheable asset on the site, and the origin stops seeing traffic that is policy-static.