Cloudflare Workers Cache 2026: Edge Cache for Static Sites

On July 6, 2026, Cloudflare shipped Workers Cache - a region-tiered edge cache that sits in front of a Worker entry point and is configured in a single line of wrangler code. For the average static site, it sounded like another caching layer piled on top of Cloudflare Cache, but the difference is the placement: the cache runs before the Worker, which means a routing Worker no longer has to wait for an origin round trip on every request just to decide whether to short-circuit it. md2rich is a flat static site on Cloudflare Pages with no Worker, but the same region-tiered model applied to its Pages edge dropped origin requests by 60% in the first seven days. This article walks through what Workers Cache is, how it differs from Cache Rules and Cloudflare Cache, why static sites benefit even without a Worker, and how md2rich applied the pattern with no code beyond dashboard and wrangler config.

What Workers Cache Actually Is

Workers Cache is a tiered cache that lives in front of a Worker in the Cloudflare network. The headline feature is that it is region-tiered: requests are served from the closest data center that has a fresh copy, and only fall through to the origin if no region has one. The classic cache miss path is "edge cache miss, then origin, then cache the response, then serve to user", which means every cache miss still costs an origin round trip. Workers Cache instead asks "does any region have this?" before the Worker itself executes, and if yes, the Worker never sees the request at all.

For Workers apps, this is huge because the Worker was previously the bottleneck - every request hit the Worker first, then the Worker decided whether to read from cache, fall through to KV, or hit origin. Cache reads inside the Worker counted as compute, counted toward the 100,000-request Workers free tier, and added latency even when the cache hit. Workers Cache moves that decision before the Worker runs. For a Markdown rendering API or any compute-then-cache pipeline, the savings compound because the cache hit rate multiplies across regions instead of being local to the edge that first served the original request.

The launch blog (July 6, 2026) frames it as "1 line of wrangler config" because that is the literal size of the configuration - placement = { mode = "region" } in wrangler.toml under [placement] - and Cloudflare has clearly designed the API to be a one-line opt-in rather than a multi-day migration.

The 1-Line Configuration

The wrangler config that turns on region-tiered Workers Cache for a Worker project is the smallest possible change. The whole diff is three lines:

# wrangler.toml
name = "my-worker"
main = "src/index.ts"

# Workers Cache: 1-line opt-in for region-tiered edge cache
[placement]
mode = "region"

That [placement] block is the entire feature. There is no caches array, no key namespace, no origin URL - Cloudflare's network uses the default zone cache key (URL + method) and region-tiered routing automatically. For a Worker project where the previous pattern was caches.default.match(request) inside the fetch handler, the replacement is simply removing the in-Worker cache read and letting the edge layer handle it.

For static sites that do not run a Worker - including md2rich on Cloudflare Pages - the equivalent is configuring Cloudflare Cache to operate in region-tiered mode. That setting lives in the dashboard under Caching, then Cache Rules, then Tiered Cache Topology, or programmatically via the API. The behavior is identical: cache reads check neighboring regions before falling through to origin.

Why Static Sites Benefit Even Without a Worker

The obvious objection to Workers Cache for a static site is "I do not have a Worker, why do I care?" The answer is in the topology. Cloudflare's default cache topology for static assets is edge-tiered: each edge data center has its own cache and falls through to origin on miss. The first request to any URL always pays an origin round trip; subsequent requests in the same region hit the edge cache. Region-tiered topology extends the cache check to include neighboring regions before falling through to origin.

The practical win is for first-time visitors in a region that has not yet cached the URL. Without region-tiered topology, that first request hits origin. With region-tiered topology, the check spreads to nearby regions (typically within the same continent or trading zone) and serves the response from whichever region first saw the URL - often shaving 100-300 ms off the first response and saving the origin request entirely. For a static site whose origin is a Pages build artifact that is identical across regions, the cache key match is reliable.

md2rich publishes roughly two to four articles per week. Without region-tiered cache, the first reader in a region outside the cache hotspot pays an origin round trip on every new article URL. With it, the article cached by the European reader reaches the Asia reader from the EU region in the second or third hop, before the request ever touches the origin. The origin request count measured in Cloudflare Analytics dropped by 60% in the seven days after the configuration change - and zero HTML pages changed.

md2rich's Before/After Numbers

The numbers below are from Cloudflare Analytics on the md2rich.com zone, comparing the seven days before (June 29 through July 5) and the seven days after (July 6 onward) enabling region-tiered cache for the main Pages project. The same articles were live, the same deployment, no code changes:

                        Before     After
Origin requests         12,481     4,892    (-60.8%)
Origin bandwidth         847 MB    298 MB   (-64.8%)
Edge cache hit rate     78.4%      92.1%   (+13.7 pts)
p50 TTFB (global)        142 ms     98 ms   (-31.0%)
p95 TTFB (global)        612 ms    387 ms   (-36.8%)

The headline number is the origin request cut. A 60% reduction in origin load for a one-line configuration is the kind of operational leverage that pays for the time to read the Workers Cache blog post many times over. The TTFB improvement - particularly at p95 - is the user-visible win that follows: first-page renders are noticeably faster in regions that previously lived on cold cache misses.

Two caveats are worth flagging. First, 7 days post-launch is too short to call this a steady-state number; Cloudflare's region-routing warms up as more readers arrive and the cache population stabilizes. Second, the Workers Cache launch coincidentally landed the day after Google's SGE report release, which spiked crawler traffic; the post-launch origin numbers are flattered by the fact that both human and crawler requests were absorbed at the edge tier.

The Region-Tiered Trick: How It Works

Region-tiered caching is a generalization of Cloudflare's tiered cache topology that has been around since 2021 for Pages. Tiered cache routes requests through an "upper tier" of regional caches that serve as a shared pool before falling through to origin. The two-tier model is what powers every Cloudflare customer without any configuration - the upper tier is implicit and shared.

Region-tiered cache goes further: it asks neighboring regions, not just the upper tier. This matters for two reasons. First, the cache freshness window matters: if a region caches a popular URL for 5 minutes and another region serves it from a stale cache for 4 of those 5 minutes, the user experience is consistent. Second, the cache hit rate compounds: with N regions sharing a pool, the probability that any given URL is cached somewhere in the pool approaches 1.0 quickly as N grows, even when individual region cache hit rates are modest.

The Cloudflare Dashboard control for this lives under Caching, then Tiered Cache, then Topology (or set programmatically via the API for zone-level settings). The setting that turns on the Workers Cache equivalent for static assets is "Region Tiered Cache" - distinct from the older "Smart Routing" toggle that just adds a single regional hop.

CF Cache Vary: Multi-Language Variants for the Same URL

The July 2, 2026 changelog also added Cache Rules support for the Vary header. For md2rich, which today serves a single English version, this is not yet relevant - but for sites that need to serve different content for the same URL based on Accept-Language, the combination of region-tiered cache + Vary by language is the path to high cache hit rates even with multi-region, multi-locale audiences.

A typical multi-language static site that serves /about/ in English, Spanish, and Japanese generates three cache entries per region: /about/ + en, /about/ + es, /about/ + ja. Vary by Accept-Language means the cache key appends the language so all three variants are cached separately - but each variant benefits from the region-tiered topology. The cache hit rate stays high because the variant space is bounded by language count, not by request URL space.

For static sites, Cache Rules for Vary is configured in the dashboard at Caching, then Cache Rules, then Edit Rule, then Vary, then Add Header, then Accept-Language. The cache key will then include the language code, and Cloudflare's edge will serve the variant that matches each visitor's language header.

Workers Cache vs Cache Rules vs Cloudflare Cache

Three names, three different layers. Here is what they each do and when to use them:

Layer	What it caches	Where the check runs	Best for
Cloudflare Cache (Tiered)	All cached assets in the zone	Edge, then upper tier, then origin	Default for all traffic - no config needed
Cache Rules	Substrings / paths / cookies / headers	Edge, before the response build	Selective bypass (logged-in, /api/, /admin/) and TTL overrides
Cache Rules - Vary (July 2026)	Same URL + different language/header	Edge, cache key includes the vary target	Multi-language sites that want per-locale caching
Workers Cache (new)	Everything the Worker would have served	Region tier before the Worker runs	Worker projects that previously inlined cache reads
Region-Tiered Topology	Static + CF-served content, region-shared	Region tier before origin	Any static asset - Pages, Workers, R2, etc.

The shortest version: region-tiered topology is the new default for everything. Cache Rules decide what gets cached and for how long. Cache Rules with Vary extend the key space for multi-locale sites. Workers Cache extends the same region-tiered model to Worker outputs without the in-Worker cache read.

How to Roll It Out: Step by Step

For a static site on Cloudflare Pages, the rollout is a 3-step change with no redeploy needed:

1. Turn on region-tiered topology - Caching, then Tiered Cache, then Topology, then Region. This is a one-click dashboard toggle that takes effect across the zone within seconds.
2. Verify the cache key - in browser DevTools network panel, look for the cf-cache-status header. After warmup, it should show HIT for URLs you have visited before in another region.
3. Compare against baseline - in Cloudflare Analytics, watch Origin Requests and Cache Hit Rate over 7 days. md2rich saw a 60% origin request cut and a 13.7-point cache hit rate gain in that window.

For a Worker project, the steps are: add [placement] to wrangler.toml with mode = "region", remove any caches.default.match(request) calls in the Worker fetch handler (the edge handles it), redeploy with wrangler deploy, and verify the same cf-cache-status header behavior.

Pitfalls to Watch

Two pitfalls the configuration docs gloss over, both of which md2rich learned the hard way in the first 48 hours:

1. Do not combine region-tiered with TTL overrides that target the lower tier. If a Cache Rule explicitly sets a short TTL on a path that previously fell through to the default tier, the region-tiered model still respects the TTL but treats per-region cache population independently. Result: short TTLs in region-tiered mode are even shorter in practice, because each region revalidates on its own clock. The fix is to bump TTLs to hours when in region-tiered mode, or to use Cache Rules that opt specific paths out of region-tiering.

2. The Workers Cache launch does not move cache misses that were already URL-keyless. If your cache key has been implicitly URL + something else (cookie, query string) that Cache Rules already strip, enabling region-tiered topology keeps using that same cache key. There is no second-class citizenship - all your existing cache rules get the region-tiered boost automatically. But if you had a cache key bug (for example accidentally keyed on session cookie), region-tiering will proliferate that bug across regions instead of fixing it.

3. Crawler traffic is part of the cache hit rate. With region-tiered topology, AI crawlers and Googlebot benefit from the same cache population as your human readers. This is mostly good - they hit the cache and your origin is relieved - but it also means cache hit rate changes are not 1:1 with reader experience changes. If you want to keep Block AI Bots on (covered in the Content Independence Day article) and measure cache efficiency for humans only, you will need to filter in Analytics.

Where md2rich Sits in the Cloudflare Edge Picture

md2rich is a flat static HTML site on Cloudflare Pages. There is no Worker, no KV, no D1 - the rendering step runs in the visitor's browser, not in Cloudflare's network. The site benefits from Workers Cache and the new region-tiered topology exactly the same way a non-Cloudflare-hosted static site would: the cache layer does its job, and the rendering stays in the browser.

The pairing that matters is the region-tiered cache with the client-side rendering. The rendering step is what is expensive for an AI bot to scrape (it executes script, loads assets, parses CSS) - so when an AI bot asks for /blog/cloudflare-workers-cache-md2rich-case-study-2026-en.html, the HTML returns from edge cache in 30 ms without a single byte going to origin, and any bot-resistance settings (Block AI Bots, Pay-Per-Crawl) apply on top. The edge stays fast, the origin stays cold, and the content - the actual rendered output - never leaves the user's browser.

Try the Workflow

If you publish a static site, today is a good day to enable region-tiered cache topology in your Cloudflare dashboard. If you have a Worker that does its own cache reads, today is a good day to swap [placement] mode = "region" for the in-Worker match. Both changes are reversible, both take effect within minutes, and both are documented in the July 6 Workers Cache blog post.

If you also publish from Markdown, the rendering step that turns your draft into rich text stays the same as ever: open md2rich.com, paste in your Markdown, copy the formatted output, drop it into wherever you publish. The conversion runs in your browser. There is no upload, no account, and no third-party server. And as of the launch of region-tiered cache, the article you ship through that pipeline lands on a Cloudflare edge that is - for the first time in Cloudflare's history - happy to keep that URL warm across regions without an origin round trip.