Static Site Generators in Production

Tiered Caching and Origin Shield

A CDN has hundreds of edge locations, and each keeps its own cache. For a popular page, every edge quickly holds a copy. For the rarely visited majority of a static site — the 1,800 documentation pages that each get a handful of views a day from around the world — most edges never see enough requests to keep a copy warm, especially when HTML has a short lifetime so deploys show up quickly. Each of those misses travels to the origin: an S3 bucket in one region, a small VM, a Pages project. Readers far from the origin wait for the round trip, and the origin serves far more traffic than a "cached" site should.

Tiered caching fixes this by putting a smaller number of upper-tier caches between the edges and the origin. An edge miss asks the upper tier first; only an upper-tier miss goes to the origin. This guide enables it on Cloudflare (Tiered Cache) and CloudFront (Origin Shield), explains how to pick the tier location, and measures the effect on a 2,300-page documentation site with a global audience. It is part of CDN Caching Rules for SSGs.

Prerequisites

  • A static site behind Cloudflare or CloudFront with correct cache headers — hashed assets immutable, HTML revalidated or with a short edge TTL, as in Stale-While-Revalidate for Static HTML.
  • CDN logs or analytics that show cache status and origin requests.
  • Knowledge of where the origin is and where readers are.

Why Rarely Visited Pages Miss

On the documentation site, the top 100 pages received 52% of views and the remaining 2,200 pages the other 48%. HTML had an edge TTL of 10 minutes with stale-while-revalidate, so deploys appeared quickly. For a page viewed 20 times a day, spread over 300 edge locations, almost every view was the first at its edge within the TTL window — a miss. The measured edge hit ratio for HTML was 71% overall and 38% on pages outside the top 100.

Edge hit ratio for top pages and rarely visited pages before and after tiered caching Paired bars. The top 100 pages had an edge-or-tier hit ratio of 94 percent before tiered caching and 98 percent after. The remaining 2,200 rarely visited pages had 38 percent before and 91 percent after, because upper-tier caches served most edge misses. HTML hit ratio, popular versus rarely visited pages Edges only With tiered cache Top 100 pages 94% 98% Rarely visited (2,200 pages) 38% 91%
One week of Cloudflare analytics before and after enabling Smart Tiered Cache; hit counts include upper-tier hits.

How the Tiers Work

With tiering, requests flow in three steps:

  1. The reader's nearest edge checks its cache. Hit: done.
  2. On a miss, the edge asks its upper tier — a regional data centre that serves many edges. Hit: the edge stores a copy and responds.
  3. On an upper-tier miss, the upper tier fetches from the origin, stores a copy, and passes it down.

Because hundreds of edges share a handful of upper tiers, an upper tier sees enough traffic to keep even rarely visited pages warm. And because concurrent requests for the same object are collapsed at the tier, a burst of traffic after a deploy produces one origin request per object instead of one per edge.

Request path for a rarely visited page with tiered caching A reader in Sydney requests a rarely visited page. The Sydney edge misses. With tiered caching, it asks the upper tier in Singapore, which has the page cached and returns it in about 90 milliseconds. Without tiering, the edge would fetch from the origin in Frankfurt, taking about 310 milliseconds. Only an upper-tier miss goes to Frankfurt. An edge miss with and without a tier Reader Sydney Edge SYD Upper tier SIN Origin Frankfurt S3 GET /docs/guide/proxy/ edge miss → ask upper tier tier hit, ~90 ms only on a tier miss (~310 ms total)
Latencies are medians from RUM and CDN logs for Australian readers.

Step 1: Cloudflare Tiered Cache

On Cloudflare, Tiered Cache is a zone setting. Smart Tiered Cache, available on all plans, picks the upper tier closest to the origin based on latency measurements; Generic Global Tiered Cache uses several upper tiers; Regional Tiered Cache (Enterprise) adds a middle layer.

curl -X PATCH "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/cache/tiered_cache_smart_topology_enable" \
  -H "Authorization: Bearer $CF_API_TOKEN" -H "Content-Type: application/json" --data '{"value":"on"}'

Or in Terraform with cloudflare_tiered_cache { zone_id = …, cache_type = "smart" }. For sites on Cloudflare Workers static assets or Pages, the static files are already served from Cloudflare's storage close to the edge, so tiered caching mainly helps when the zone proxies an external origin such as S3 or a VM. The documentation site proxied a Frankfurt S3 bucket through a Cloudflare zone, the case where it matters most.

Step 2: CloudFront Origin Shield

On CloudFront, Origin Shield is enabled per origin and needs a region. Choose the AWS region closest to the origin — for an S3 bucket in eu-central-1, choose eu-central-1:

"Origins": { "Items": [{
  "Id": "docs-s3",
  "DomainName": "docs-bucket.s3.eu-central-1.amazonaws.com",
  "OriginShield": { "Enabled": true, "OriginShieldRegion": "eu-central-1" },
  "S3OriginConfig": { "OriginAccessIdentity": "" },
  "OriginAccessControlId": "E2QWRUHAPOMQZL"
}]}

CloudFront already has regional edge caches between edges and origins by default; Origin Shield adds one more centralized layer in front of the origin. It is billed per request that reaches the shield, so it pays off when it significantly reduces origin requests — heavily with S3 cross-region data transfer, less so for an origin in the same region as most readers.

Step 3: Choosing the Tier Location

The upper tier should be close to the origin, not to the readers: the expensive and slow part is the trip to the origin, and a tier near the origin makes that trip short while remaining reachable from all edges over the CDN's backbone. Placing CloudFront's shield in us-east-1 for a Frankfurt bucket in an early test made things worse for European readers — edge misses crossed the Atlantic twice — and origin requests fell by less than with the shield in eu-central-1.

Choosing an upper tier location relative to origin and readers The root asks where the origin is. For a single-region origin such as S3 in Frankfurt, put the tier in the same region to minimise origin round trips. For an origin already on the CDN, such as Workers static assets or Pages, tiering adds little. For multiple origins in different regions, use the CDN's smart or global topology rather than one fixed region. Where should the upper tier be? Where does the origin live? One region (S3 or a VM) Tier next to origin e.g. eu-central-1 shield On the CDN itself Little benefit Workers assets or Pages Several regions Smart or global topology let the CDN choose
A tier near readers but far from the origin can increase latency; the test with a US shield for a Frankfurt bucket did.

Deploys and Purges With Tiers

Tiers add a cache layer that purges must reach. Both Cloudflare and CloudFront purge upper tiers along with edges, so a purge after deploy works as before, as in Purging the CDN Cache After a Static Deploy. What changes is the refill: after a purge, the first request per object in each tier region goes to the origin, and every edge after that fills from the tier. On the documentation site, origin requests in the ten minutes after a full purge fell from about 48,000 to 6,500 with tiering, which removed the origin load spike that had occasionally caused S3 throttling (503 SlowDown) on large deploys.

Watch one more thing after enabling tiers: the cache status field in logs gains new values (Hit from the upper tier appears as a hit at the edge on Cloudflare, while CloudFront reports Hit or RefreshHit at the edge and records shield hits separately), so dashboards that computed hit ratio from edge status alone may need adjusting to count tier hits correctly.

Measured Impact

Two weeks before and after enabling Smart Tiered Cache on the Cloudflare zone in front of the Frankfurt bucket:

MeasureEdges onlySmart Tiered Cache
HTML hit ratio (edge + tier)71%95%
Rarely visited page hit ratio38%91%
Origin requests per day118,00017,000
S3 GET requests and egress cost per month61 USD11 USD
TTFB p75 for edge misses, APAC readers310 ms120 ms
LCP p75, APAC readers2.2 s1.8 s
Origin requests in 10 min after full purge~48,000~6,500
Daily origin requests before and after tiered caching Vertical bars of origin requests per day. Edges only 118,000. With Smart Tiered Cache 17,000, an 86 percent reduction. Origin requests per day 118,000 Edges only 17,000 Smart Tiered Cache
Two-week averages from S3 request metrics; site traffic was similar in both periods.

Pitfalls & Rollback

  • Tier far from the origin. Adds a long hop and saves little; keep the tier near the origin.
  • Expecting tiering to fix bad headers. no-store or cookie-varying responses are not cached at any tier.
  • Paying for Origin Shield without measuring. When the origin is already close and cheap, the extra request charges can exceed savings.
  • Fragmented cache keys. Tiers multiply the benefit of a clean key; fix query-string fragmentation first, as in Cache Keys and Query Strings on CDNs.
  • Rollback: both features are single settings; disabling them returns to edge-only caching immediately.

Conclusion

Tiered caching is the missing piece for static sites with many rarely visited pages and a global audience: edge misses are served from a regional tier near the origin, so the origin sees a fraction of the traffic and distant readers get faster first views. Put the tier next to the origin, fix the cache key first, and measure origin requests and miss latency. On this site it cut origin requests by 86% and TTFB on edge misses by more than half.

FAQ

What is tiered caching?

A CDN setup where edge locations that miss the cache ask a smaller set of upper-tier or regional caches before going to the origin. Only a miss at the upper tier reaches the origin, so origin requests fall and edges in regions with little traffic get warm content faster.

What is an origin shield?

CloudFront's name for a designated regional cache that all edge locations use as their upper tier for a distribution. It collapses requests from many edges into one request to the origin per object.

Do static sites benefit from tiered caching?

Yes, especially sites with a global audience, many pages that each get modest traffic, short HTML cache lifetimes that expire often, and origins that are slow or charge for egress, such as object storage in a single region or a small VM.

Does tiered caching add latency?

On an upper-tier hit it adds one hop between the edge and the tier, typically 20 to 60 milliseconds, but saves the much longer trip to a distant origin. On an edge hit nothing changes. On the site measured here, median TTFB for edge misses fell from 310 to 120 milliseconds.

Filed underHow-tosCloudflareAWS (S3 and CloudFront)