Your Worker can now have its own cache in front of it (opens in new tab)

Workers Cache places a tiered Cloudflare cache directly in front of a Worker, allowing cacheable responses to be served without running the Worker or incurring CPU time. It is enabled with a single Wrangler configuration block and controlled through standard HTTP headers such as Cache-Control and Cache-Tag. The feature gives server-rendered applications a middle ground between expensive per-request rendering and slow, rebuild-dependent static generation.

How Workers Cache Works

• Enable it in Wrangler with:

  { "cache": { "enabled": true } }
  

• Cacheable requests are checked against Cloudflare’s cache before the Worker runs.
• Cache hits return immediately without invoking the Worker or consuming CPU time.
• Cache misses execute the Worker, and cacheable responses are stored for later requests.
• Caching follows the Worker across:
  • Custom domains
  • workers.dev
  • Service bindings
  • Preview environments
  • Workers for Platforms tenants
• Responses use familiar HTTP controls:
  • Cache-Control for TTL and behavior
  • stale-while-revalidate for background refreshes
  • Vary for content negotiation
  • Cache-Tag for targeted invalidation

Purging Cached Content

• Workers can purge their own cache programmatically:

  await ctx.cache.purge({ tags: ["product:123"] });
  

• Purging can target cache tags or path prefixes.
• ctx.props supports cache keys that are safe for multi-tenant applications.

Why Server-Rendered Apps Need This

• Originally, Workers were positioned in front of an origin and Cloudflare’s cache.
• Modern frameworks such as Astro, Next.js, Remix, SvelteKit, and TanStack Start often make the Worker the application’s origin.
• Without a cache in front, every request runs application code, even when the response has not changed.
• This creates recurring rendering latency and CPU costs for server-rendered pages.

A Middle Ground Between Static and Dynamic Rendering

• Static-site generation provides fast responses but requires rebuilding and redeploying whenever content changes.
• Rendering every request keeps content current but imposes latency and compute costs on every visitor.
• Workers Cache enables on-demand rendering:
  • The first request renders and caches the page.
  • Subsequent requests are served from cache.
  • Expiration triggers a fresh render according to the configured TTL.
• This delivers static-like speed without framework-specific systems such as Incremental Static Regeneration.

Stale-While-Revalidate

• stale-while-revalidate allows Cloudflare to serve an expired response immediately while refreshing it in the background.
• Without it, the first request after expiration waits for the Worker to render the page again.
• With it:
  • Users receive the stale response instantly.
  • The response includes Cf-Cache-Status: UPDATING.
  • The Worker refreshes the cached response asynchronously.
• A typical policy is:

  Cache-Control: public, max-age=300, stale-while-revalidate=3600
  

  This keeps content fresh for five minutes while allowing stale content to be served for up to an additional hour during background refreshes.

Workers Cache is available to all Workers on every plan. For server-rendered applications, enabling it and defining appropriate HTTP cache headers provides a simple way to reduce latency and execution costs while retaining controlled content freshness.