Cloudflare pushed two changes to its edge platform this month that change how sites built on its network handle caching. On July 6 the company launched Workers Cache, a tier that sits in front of a Worker and serves responses without running code. On July 10 it extended Smart Tiered Cache so that origins hosted on AWS, Google Cloud, Azure, and Oracle Cloud can be pinned to the right upper-tier data center through a simple region hint.
Both moves target the same problem: getting content to users from the closest possible location while keeping compute and bandwidth bills down.
The shift matters because Workers stopped being a bolt-on and became the server. Frameworks such as Astro, TanStack Start, Next.js, Remix, and SvelteKit all ship a Cloudflare adapter that builds the app as a Worker. There is no origin behind them. The Worker is the origin.
Why server-rendered apps needed a cache in front
When Cloudflare introduced Workers in 2017, the idea was to run code on its network to transform requests on the way to an origin. The Worker sat in front of the cache and the origin. That worked for adding headers, rewriting URLs, or filtering traffic before it reached your backend.
The model broke down once the Worker became the origin itself. With nothing behind it, the original architecture had nothing to cache. Every request ran the code, even when the response would be byte-for-byte identical to one returned a second earlier.
Cloudflare says its runtime is fast enough to render tens of millions of requests per second. Fast enough still costs latency on every page load and CPU time on every invocation. On a server-rendered app, every page load is a render by definition.
Before Workers Cache, teams picked between two weak options. They could prerender everything at build time, which meant a full rebuild on every change. Or they could render every page on every request, which paid the rendering cost on every visitor.
A cache that follows the Worker everywhere
Workers Cache flips the layout. Cloudflare's cache now sits in front of the Worker. On a cache hit, the Worker does not run and the CPU billing stays at zero. On a miss, the Worker runs once, populates the cache, and the next request from anywhere gets served from cache.
The setup is one config block in Wrangler:
{
"name": "my-worker",
"main": "src/index.ts",
"compatibility_date": "2026-05-01",
"cache": {
"enabled": true
}
}From there, developers control caching with the same Cache-Control headers they already know. A product catalog that updates every few minutes can use max-age=300, stale-while-revalidate=3600. A blog archive that rarely changes can use max-age=86400. The Worker purges its own cache by tag when content changes.
The feature shipped with full support for stale-while-revalidate, which Cloudflare added in February 2026. When a cached response expires, Cloudflare serves the stale copy immediately and refreshes it in the background. The user never waits.
Cloudflare made Workers Cache available to every Worker on any plan, turned on in Wrangler. The cache follows the Worker wherever it runs: a custom domain, workers.dev, behind a service binding, in a preview, or inside a Workers for Platforms tenant. One Worker, one cache, configured once.
The announcement landed alongside a run of edge-platform updates from the company this month. Cloudflare described Workers Cache as the caching API it had always wanted Workers to have, and said the wait came down to reworking where the cache sits relative to user code.
Smart Tiered Cache learns your cloud region
The second change fixes a longer-running problem with Smart Tiered Cache, first shipped in 2021. The service picks a single best upper-tier data center for each origin based on real-time latency. Flip one switch and Cloudflare finds the fastest path from its network to the origin. It has become the most-used tiered cache topology among Cloudflare customers and is free on all plans.
That logic works when an origin IP lives in one fixed place. Public cloud origins usually don't. They sit behind anycast or regional unicast front ends, so one origin IP can look equally close to a dozen Cloudflare data centers at once. The latency probes have nothing to lock onto.
Cloudflare handled this the safe way: when there was no clear winner, it fell back to several upper tiers. Nothing broke, but cache efficiency dropped because traffic spread across multiple tiers instead of concentrating at one.
On July 10 the company closed the gap for origins hosted on AWS, GCP, Azure, and Oracle Cloud. Customers now supply a cloud region hint, such as aws:us-east-1 or gcp:europe-west1, through the dashboard, the API, or Terraform. With the hint, Cloudflare maps the origin to the right region and selects better primary and fallback upper tiers even when the IP looks anycast.
Killing the cross-continental hairpin
The cost of getting this wrong is real. Cloudflare described a hairpin case: an origin in Singapore behind an anycast IP. Because of how anycast works, a Chicago data center might show the lowest probe latency to that IP. Smart Tiered Cache would then pick Chicago as the upper tier. A user in Asia hits a nearby Cloudflare data center, gets routed cross-continent to Chicago, and Chicago fetches from the origin back in Singapore. That round trip crosses the ocean twice and adds hundreds of milliseconds.
To spot anycast origins, Cloudflare uses a constraint from physics: the speed of light. It measures probe latencies from multiple checkpoint data centers to the origin. If the combined latencies from two checkpoints are faster than light in fiber could physically travel between them, the origin must be answering from multiple locations. That tells Cloudflare the IP is anycast.
With a region hint, the system skips the guessing. Every few hours it pulls the latest IP range files from each supported provider and matches those subnets against an upper-tier database built from latency probing refreshed every 15 minutes. The upper tier with the strongest signal becomes the region's primary. Primary and fallback always come from different points of presence, so losing one site can't take out both.
Regions with thin probe data fall back to geography: the closest Tier 1 point of presence. As origins come online and probe data builds, the region switches from that guess to the option backed by real measurements.
What it means for the edge
Cloudflare runs its network across more than 300 cities in over 100 countries, according to the company's own network page. Roughly one in five websites worldwide sits behind some part of that network. Changes made at this scale ripple out to a large slice of the Internet.
For builders, the two releases remove friction that pushed teams toward heavier workarounds. Workers Cache gives server-rendered apps the speed of a static site without the rebuild tax, and the freshness of server rendering without the per-request cost. Smart Tiered Cache for Public Cloud Regions removes a cross-continent detour that cloud-hosted sites hit through no fault of their own.
The pieces fit a wider trend on this beat. Our Cloud & Edge Computing coverage has tracked metro data centers pulling inference closer to users, and our cybersecurity coverage has followed Cloudflare's role as a front-line defense. Caching and routing at the edge are the plumbing underneath both.
Cloudflare is not alone in pushing compute to the edge. AWS Lambda@Edge and CloudFront Functions, and similar offerings from other providers, already run logic close to users. What changed this month is that Cloudflare made its cache a first-class citizen in front of user code, and gave its routing layer a direct read on where cloud origins actually live.
The practical upshot is dull but welcome: fewer wasted round trips, lower CPU bills, and pages that load as if they were static even when they were rendered on demand seconds ago. The full details are in Cloudflare's posts on Workers Cache and Smart Tiered Cache for Public Cloud Regions.