Why it matters
Caching bugs rarely show up when you set the headers. They show up days later: a deploy goes out and some visitors get yesterday's HTML pointing at deleted JavaScript, or an API keeps serving an old price for five minutes, or the CDN never caches anything because of one stray directive. The directives interact in ways definitions don't make obvious: s-maxage only applies to the CDN, a browser that gets its copy from the CDN counts the CDN's Age against its own max-age, and no-cache doesn't mean don't cache.
This simulator applies the RFC 9111 rules step by step. Each visitor has their own browser cache, everyone shares one CDN, and each request is followed through both to the origin and back. You see which layer answered, whether it was a full download or a 304, and which visitors got the old version after a deploy and for how long. Checks flag conflicting or risky headers, and each preset comes with recommended headers. It's a model of a standard cache: individual CDNs have extra rules, so check yours.
How it works
- InputResponse headers and a request schedule
- In your browserEach request through browser, CDN and origin
- OutputHits, 304s, stale copies and better headers
Where it fits in a designer's workflow
- Plan
- Design
- Build
- Test
- Launch
By the numbers
Show the numbers as a table
| Preset | Requests | Browser cache | CDN | Origin | Old version served |
|---|---|---|---|---|---|
| HTML page, max-age=3600 | 7 | 3 | 2 | 2 | 3 |
| Hashed file, immutable | 5 | 2 | 2 | 1 | 0 |
| API JSON, s-maxage + SWR | 7 | 1 | 4 | 2 | 2 |
How to use it
- Pick what the response is, or paste your own response headers.
- List requests as a time and a visitor letter: 0 A, 2m B, 1h A.
- Set when a new version is deployed.
- Read the timeline and the summary, then compare with the recommended headers.
FAQ
What's the difference between no-cache and no-store?
no-store means don't keep a copy at all. no-cache means keep it, but check with the server before every use; with an ETag that check is a small 304 instead of the whole response.
Why did the browser's copy expire early?
When a browser gets its copy from a CDN, the response carries an Age header saying how long the CDN has had it. The browser counts that against max-age, so a 10-minute max-age with Age: 2 minutes leaves 8.
What does stale-while-revalidate do?
For a set time after expiry, a cache can answer at once with the stale copy and fetch a fresh one in the background. Visitors get speed; the next one gets the new version.
How do I avoid old pages after a deploy?
Give static files a content hash in the name and cache them for a year with immutable. Keep HTML short-lived at the CDN, revalidated in the browser, and purge the CDN when you deploy.
Does it model my CDN exactly?
It models a standard RFC 9111 shared cache and reads CDN-Cache-Control. CDNs add their own rules, such as minimum TTLs, ignoring some directives or caching only some file types, so check your provider's docs.
