Laura: Okay, Cloudflare just dropped something that is actually the missing piece for server-rendered apps on Workers, and I'm not even trying to hype it — this is the one we've been waiting for.
Harper: Yeah?
Laura: Workers Cache. One line in Wrangler, Cache-Control headers you already know, and suddenly your Worker has a tiered cache sitting in front of it. On hit, Worker doesn't run. Zero CPU. On miss, Worker runs, populates cache, and the next request from anywhere gets served straight from cache without ever touching your code.
Harper: Hold on — cache in front of the Worker, or cache in front of the origin behind the Worker?
Laura: In front of the Worker itself. Because the Worker IS the origin now. That's the whole shift. Back in 2017, Workers were a transformation layer you bolted onto an origin — rewrite a URL, add a header, filter traffic. The cache sat behind them. But then Astro, Next.js, Remix, SvelteKit all shipped Cloudflare adapters, and now the Worker is the server. There's no origin behind it.
Harper: So the old architecture doesn't cache anything.
Laura: Nothing. Every request runs your code, even if the response is byte-for-byte identical to the one you returned a second ago. Workers runtime is fast enough that it works, but you're still paying latency and CPU on every page load. And on a server-rendered app, every page load is a render.
Laura: So this flips it. Cache in front, Worker behind. Cache hit, Worker doesn't run. Miss, Worker runs once, populates cache, and the next request — from anywhere on Earth — gets served from cache without your code.
Harper: That's the architecture move. What about the mental model?
Laura: This is where it gets good. You used to have two bad options: prerender everything at build time — fast page loads but five to ten minutes of rebuild every time anything changes. Or render every page on every request — up-to-date content but you pay the rendering cost on every visitor.
Harper: Right…
Laura: Workers Cache gives you a third: server-render on demand, cache the rendered response, refresh it on a TTL you pick. First request to a new page still renders. Every subsequent request until cache expires is served as if the page were static. When cache expires, next request triggers a re-render — and with stale-while-revalidate, even that one doesn't wait.
Harper: Stale-while-revalidate is doing the work there.
Laura: Completely. On cache expiration, it serves the stale copy immediately while the Worker refreshes in the background. No user waits. So for a product catalog that updates every few minutes, you set max-age=300, stale-while-revalidate=3600 — visitors basically never wait, and your Worker still runs often enough to keep content fresh.
Harper: Okay, so the mental model is: fresh window, Worker doesn't run. Stale window, Worker runs in the background. Outside both windows, user waits. You pick the windows.
Laura: Exactly. You own it in code.
Harper: The other thing in here that's solid is Vary. They're doing content negotiation the HTTP standard way.
Laura: Right — same URL, multiple representations. WebP for browsers that support it, JPEG for the ones that don't. English, French, Japanese depending on the user. Most caches give you two bad options: cache nothing, or cache one representation and serve it to everyone.
Harper: Workers Cache implements Vary the way RFC 9110 describes. No allowlist. You list the headers you need, it caches separate variant per distinct combination, only returns the variant whose stored values match the incoming request.
Laura: So the Worker writes both variants on the first request to each, and then runs zero times for either after that.
Harper: That's the move.
Laura: And because it's per-entrypoint cache control, you can compose caching directly into the structure of your app. Chain of entrypoints with cache stages slotted in wherever you want, configured by the code on either side. One Worker, one cache, configured once.
Harper: Mm-hm.
Laura: This is the boring HTTP win we keep landing on. They didn't invent a new cache primitive or a harness language — they took the standards that already exist, put them in front of the Worker, and let the code be the configuration surface.
Harper: And it's available today to every Worker on any plan. Just enable it in Wrangler.
Laura: So this is the thing I was waiting for. Server-rendered apps on Workers without build time, without paying rendering cost on every page load, without choosing between stale and slow. You get the speed of a static site and the freshness of server rendering.
Harper: That's the unlock.
Laura: Yeah, I think this actually ships and sticks, Harper. Seventy-thirty it's in production on a meaningful percentage of Workers-based apps within a year.
Harper: I'd take that bet. It's the right move at the right time.
Laura: Okay, well. That's the show for this week — thanks for hanging.