Astro cache warming: prerendered, on-demand, and the Cloudflare Workers edge

We run a large content site built with Astro on Cloudflare Workers in production — content managed in EmDash, and it's the site whose cache problems turned into warmup.rocks. Astro is a great fit for edge caching because it makes the crucial decision explicit: every route is either prerendered at build time or rendered on demand. Those two kinds of routes go cold in completely different ways, and most Astro performance advice only covers the first. Here's the full map.

Layer 1: prerendered routes — cold only in one, sneaky way

Pages with prerender = true (or everything, in output: 'static') are HTML files. On Cloudflare they're served via Workers static assets, on Netlify/Vercel from their static layers. No render time, no origin — so nothing to warm, right? Almost. Static files are still delivered through a per-location edge cache: the first request in each data center fetches from the central store before that colo can serve it locally. That's a small penalty (tens of ms, not seconds), so for purely static Astro sites, warming is a nice-to-have. The real reasons to keep reading are layers 2 and 3.

Layer 2: on-demand routes — this is where the seconds live

The moment a route renders on demand (SSR with the Cloudflare adapter, Node, Vercel or Netlify), every uncached request pays: Worker/function startup, data fetches (CMS, database, APIs), and render time. Our numbers before caching HTML: 600 ms to 2 s TTFB depending on the route — for content that changes a few times a day. The fix is caching the rendered HTML at the edge, and with Astro there are two generations of doing this:

The classic way: headers you set yourself

Astro.response.headers.set(
  'Cache-Control', 'public, max-age=300, stale-while-revalidate=604800'
);

Works everywhere, but on Cloudflare it conflates two audiences: browsers and the edge read Cache-Control. You usually want browsers on a short leash (they can't be purged) and the edge on a long one (it can). The split: Cache-Control for browsers, Cloudflare-CDN-Cache-Control (or CDN-Cache-Control on other CDNs) for the edge.

The Astro 7 way: route caching

Astro 7 made this first-class: route caching lets you declare cache behavior per route pattern in astro.config, and a provider (e.g. the Cloudflare one) translates it into the right edge headers and cache tags:

// astro.config.mjs
routeRules: {
  '/blog/**': { cache: { maxAge: 86400, swr: 604800, tags: ['pages'] } },
}

Per-route overrides via Astro.cache.set() — including opting error responses out so a transient 500 doesn't get cached for a day. The Cache-Tag part is the sleeper feature: your CMS publish hook can purge exactly the affected pages instead of the whole zone.

Layer 3: the edge cache itself — per colo, and cold after every deploy

Whatever headers you send, the cache they fill is per data center. Cloudflare runs 330+ colos; a page cached in Frankfurt is still uncached in Singapore. Three production lessons from running exactly this stack (measured, not read in docs):

• Avoid s-maxage if you want background revalidation. In the Workers-fronted cache we measured that s-maxage forced synchronous revalidation — cf-cache-status EXPIRED (visitor waits) instead of UPDATING (visitor gets stale instantly). Declare SWR via route caching / Cloudflare-CDN-Cache-Control and leave s-maxage out.
• Deploys start the world cold. On Workers, the cache namespace is tied to the deployed version — ship a new build and every colo is empty at once. Deploy several times a day and "edge-cached" quietly becomes a part-time truth.
• SWR only rescues pages that are in the cache. After a deploy or on long-tail pages there's no stale copy to serve — the visitor eats the full render. Stale-while-revalidate softens expiry, not cold starts.

The warming playbook for Astro

1. Prerender everything that can be prerendered. Astro makes hybrid trivial; static routes are warm by construction (almost).
2. Give on-demand HTML real edge TTLs + SWR via route caching (Astro 7) or split cache headers — short for browsers, long for the edge.
3. Purge by Cache-Tag on publish, not "purge everything" — your content changes page by page.
4. Warm after every deploy. A deploy is your biggest cold-start event. One step in your deploy workflow — our GitHub Action or a curl to your deploy hook — re-warms every location before the first visitor notices.
5. Warm on a schedule matched to your TTLs, so long-tail pages and low-traffic regions stay hot between deploys. warmup.rocks reads your sitemap (Astro's @astrojs/sitemap output works as-is) and warms from 90+ edge locations, reporting hit ratio per location and run.
6. Verify from outside. Your own colo always looks warm. Run the cache checker for statuses per location, or the global TTFB test for what it costs your visitors.