HTTP Cache Simulator
Issue requests against a simulated cache and follow HIT, MISS, revalidation and expiry through the response lifecycle.
What you'll learn
- Read Cache-Control directives correctly
- Distinguish a fresh hit from a revalidated 304
Interactive laboratory
Controls
Interactive HTTP Cache ModelThis is a deterministic model of HTTP caching, not the browser's real HTTP cache. Times shown are simulated cache age, never network latency.
Request lifecycle
simulated clock t=0s- No request issued yet.
Cache state · /api/products
- Stored
- no
- Simulated cache age
- -
- Fresh until
- must revalidate
- ETag
- -
- Origin version
- v1
Headers in this model
Cache-Control: max-age=60 ETag: "…"
- Requests issued
- 0
- Last outcome
- -
- Source
- -
- Simulated clock
- t=0s
| # | t | Resource | Policy | Result |
|---|---|---|---|---|
| No requests yet. | ||||
What happened?
A cache HIT sends no request at all: the stored response is fresh, so the network is never touched. A 304 is not a hit - a conditional request went to the server, which answered "unchanged", saving the body but not the round trip.
max-age governs freshness; ETag/If-None-Match governs validation once a response is stale. Advance the clock past max-age=60 and request again to walk the stale path.
Why it happened
HTTP caching is a small state machine that most developers only half know.
Simulating it makes the freshness and validation rules concrete.
Key takeaways
- max-age governs freshness; ETag governs revalidation
- The fastest request is the one never sent
Tags
- http
- caching
- etag
- cache-control