Skip to main content

CDN Edge Cache Lab

Set HTTP cache headers, send traffic through Frankfurt, Virginia and Singapore CDN edges, deploy, purge and inspect shared-cache hits, misses and 304 revalidation.

Category: Networking

What You Will Learn

  • Build shared-cache keys from HTTP method, target URI, query string, and Vary
  • Choose Cache-Control directives for pages, versioned assets, and personal responses
  • Distinguish a cache hit, miss, conditional 304 revalidation, and cache bypass
  • Use stale-while-revalidate and purges to balance freshness with latency
  • Avoid tracking parameters fragmenting a CDN cache key

Topics covered: cdn, http caching, cache-control, networking, web performance, interactive

// simulator

CDN Edge Cache Lab

Set HTTP cache headers, send traffic through Frankfurt, Virginia and Singapore CDN edges, deploy, purge and inspect shared-cache hits, misses and 304 revalidation.

Supported byBecome a sponsor
BitriseAtomsizedDigitalOceanDevDojoSMTPfastQuizAPI

Ready. Press Send traffic.

0/6

Goal: Get a cache HIT at the Singapore edge. Press Send traffic. Every edge gets two visitors: the first one misses, the second one hits.

Last batch:
none yet
Hit ratio
0%
Origin requests
0
Clock
t+0s

Edge cache map

  • HITserved by the edge
  • MISSfetched from origin
  • 304origin says unchanged
  • STALEold copy, refreshing
  • BYPASSnot cacheable

Origin, Frankfurt

Serving v1 · no requests this batch

Virginia edge

idle

No requests yet

Visitors

none yet

Cached here

empty

Frankfurt edge

idle

No requests yet

Visitors

none yet

Cached here

empty

Singapore edge

idle

No requests yet

Visitors

none yet

Cached here

empty

Origin response headers

The Cache-Control header the origin sends with each response.

Cache key

About the CDN Edge Cache Lab

What you'll practise

  • Choosing cache lifetimes for HTML, hashed assets, and personal cart data
  • Reading the difference between HIT, MISS, REVALIDATED (304), and BYPASS
  • Seeing how deployment purges and no-cache change what visitors receive
  • Keeping UTM parameters from splitting otherwise identical cache entries

How it works

  • A Frankfurt origin serves three CDN edges: Frankfurt, Virginia, and Singapore.
  • Each request follows the shared-cache rules for storage, freshness, and validation.
  • The latency figures are illustrative round-trip and origin-work estimates, not measurements.
  • The lab intentionally uses no heuristic freshness when no explicit lifetime is present.

Sources

Overview

A content delivery network keeps copies of responses in edge caches close to visitors, so most requests never travel to the origin. This lab puts an origin in Frankfurt behind three edges, in Frankfurt, Virginia and Singapore, and lets you set the Cache-Control header for a page, a versioned asset and a shopping cart API. Send traffic and each edge reports a HIT, a MISS, a 304 revalidation or a BYPASS, with the hit ratio, the number of origin requests and an approximate latency per city. The rules follow RFC 9111. A shared cache must not store a response marked private or no-store. no-cache lets the edge store a response but makes it check with the origin before every reuse, and the origin can answer 304 Not Modified instead of sending the body again. s-maxage overrides max-age in shared caches, and stale-while-revalidate from RFC 5861 lets an edge serve a stale copy while it fetches a fresh one. Deploy a new version and you see why a long max-age on HTML keeps visitors on the old page until it expires or you purge it, while a fingerprinted asset can be cached for a year. The cache key is the method plus the full URL, so tracking parameters such as utm_source split one file into many cache entries unless the key ignores them.

Try this

  1. With Asset selected, press Send traffic: at every edge the first visitor misses and goes to the Frankfurt origin, and the second gets a HIT from the edge.
  2. Pick /index.html, press Send traffic, Deploy and Send traffic again: with max-age=60 the edges serve the old page until you press Wait 61 s or Purge /index.html.
  3. Change /api/cart from "private, max-age=60" to "max-age=60", send /api/cart traffic and watch the cart appear under Cached here at every edge: a shared cache storing a private page.

Frequently asked questions

What is the difference between no-cache and no-store?
no-store tells a cache not to keep the response at all. no-cache lets a cache store it, but the cache must revalidate with the origin before each reuse, usually by sending the ETag in If-None-Match. A 304 Not Modified reply lets it serve the stored copy without downloading the body again.
What does s-maxage do?
It sets the freshness lifetime for shared caches such as CDNs and proxies, and overrides max-age there. Browsers ignore it, so s-maxage=300, max-age=0 lets an edge serve its copy for five minutes while browsers revalidate on every use.
How do you make a deploy show up at once behind a CDN?
Purge the changed HTML from the edges after the deploy, or serve HTML with no-cache so edges revalidate it on every request. Give static assets fingerprinted file names with a long max-age and immutable: a new deploy changes the HTML, which then points to new asset URLs.
What is stale-while-revalidate?
A Cache-Control extension from RFC 5861. With max-age=60, stale-while-revalidate=120 a cache serves the response as fresh for 60 seconds, and for up to 120 seconds after that it can still serve the stale copy at once while it fetches a fresh one in the background.

Try next

Sponsored
Carbon Ads