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.
Ready. Press Send traffic.
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
idleNo requests yet
Visitors
Cached here
empty
Frankfurt edge
idleNo requests yet
Visitors
Cached here
empty
Singapore edge
idleNo requests yet
Visitors
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
- RFC 9111, HTTP Caching: cache keys, directives, freshness, Age, and validation.
- RFC 5861, stale-while-revalidate: serving stale responses while validation happens in the background.
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
- 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.
- 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.
- 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
// simulator
Email Authentication Lab: SPF, DKIM and DMARC
Publish SPF, DKIM and DMARC records, send mail directly and through a forwarder or mailing list, and inspect the receiver’s authentication verdict, alignment and disposition.
// simulator
HTTP/1.1 vs HTTP/2 vs HTTP/3 Lab
Load one page over HTTP/1.1, HTTP/2, and HTTP/3. Compare connection setup, multiplexed streams, TCP head-of-line blocking, and QUIC loss recovery in a request waterfall.
// simulator
Bounce Triage Simulator
Read a real SMTP bounce and decide what it is and what to do about it. Twelve genuine failures from Gmail, Outlook, Postfix and Proofpoint: hard bounces, soft bounces, content blocks, rate limits and spam complaints. Learn why the 4xx and 5xx class digit is a hint rather than the answer, which bounces to suppress permanently, which to retry, and what each mistake costs you in lost subscribers or lost sending reputation.