Edge Functions Are Moving From Always-Execute to Cache-First Architectures

Résumé

Cloudflare has introduced Workers Cache, a tiered cache that can sit directly in front of Worker entrypoints. Instead of running a Worker on every request, cacheable responses can be served from Cloudflare’s cache first. On a cache hit, the Worker does not execute, which can reduce latency and avoid Worker CPU billing for that request.

The bigger signal is architectural: edge functions are becoming less like always-on request handlers and more like composable application stages where compute, cache, routing, invalidation, and tenant isolation are designed together.

Points clés

- Workers Cache is a tiered cache positioned in front of Workers, enabled through Wrangler and controlled with standard HTTP caching headers such as Cache-Control.

- Cache hits return directly from Cloudflare’s cache, so the Worker does not run and no Worker CPU time is billed for that hit.

- The cache supports stale-while-revalidate, allowing stale responses to be served immediately while the Worker refreshes content in the background.

- Workers Cache supports content negotiation through the standard Vary header, allowing separate cached variants for different request header combinations.

- It supports multi-tenant-safe cache keys through ctx.props, so authenticated or tenant-specific responses can be cached without mixing users or tenants.

- Caching can be configured per Worker entrypoint, allowing developers to keep gateway/auth logic uncached while caching expensive backend entrypoints.

- Workers Observability now surfaces cache hit information, including hit ratio, hits, misses, updates, and bypasses alongside logs, exceptions, CPU time, and request counts.

Pourquoi cela compte

For years, edge functions were often treated as lightweight request handlers: every request arrives, code runs, a response is generated. That model is simple, but it becomes inefficient when the Worker itself becomes the origin for server-rendered apps, APIs, or expensive backend reads.

Workers Cache changes that model. It allows developers to render or compute once, cache the result, and serve later requests without invoking the Worker again. This is especially important for server-rendered applications, where many responses are dynamic enough to avoid full static generation but stable enough to cache for a short period.

The more important shift is composability. Workers Cache can sit not only in front of public Worker routes, but also in front of internal Worker entrypoints. That means developers can build applications where one stage handles authentication or routing, another stage performs expensive data access or rendering, and the cache sits between them as a first-class runtime layer.

This points to a broader infrastructure trend: edge platforms are becoming programmable delivery systems, not just places to run code close to users.

À retenir pour les constructeurs

Builders should evaluate caching as part of the application architecture, not as a CDN setting added after deployment.

For server-rendered apps, expensive API reads, Durable Object-backed workloads, or multi-tenant platforms, the key question should be:

Which parts of this workflow must run on every request, and which parts can be safely cached behind clear keys, TTLs, and purge rules?

A practical adoption path would be to start with high-traffic, read-heavy routes where responses are stable for short windows. Track cache hit ratio, misses, bypasses, CPU time, and latency before and after enabling Workers Cache. Pay special attention to tenant isolation, authorization headers, cache keys, and purge paths before applying it to authenticated or personalized workloads.