What they're testing
Whether you understand caching as a contract about immutability, or copy headers from Stack Overflow.
The short answer~30 seconds
Hashed JS: max-age=31536000, immutable — the content under that URL never changes, so caching forever is completely safe and is the entire reason filenames are hashed. HTML: no-cache — stored but revalidated every time, because it points at the hashed files and a stale copy loads a stale bundle. An avatar: a short max-age plus an ETag, or put a hash in the URL when it changes.
The long answer
no-cache is the most misleading name in HTTP: it does NOT mean "don't store" but "store it, and revalidate before using it". The meaning people assume is no-store. Distinguishing them is a frequent follow-up, because misapplying no-store to HTML forfeits the 304 path and re-downloads the whole page every time.
immutable solves a specific problem: without it, a user pressing reload makes the browser revalidate EVERY resource, including ones still fresh — dozens of pointless 304s. immutable tells the browser not to ask even on reload. It's only correct when the URL genuinely is immutable, which means content-hashed filenames.
With a CDN, add s-maxage (read only by shared caches) and stale-while-revalidate: the CDN may serve the stale copy IMMEDIATELY while fetching a fresh one in the background, so users never wait on a cache miss. It's the cheapest way to get static-page latency with content that updates by the minute.
What they'll ask next
?ETag versus Last-Modified?
An ETag fingerprints the content so it's exact; Last-Modified has one-second resolution and is wrong when a file is rewritten with identical content. Both lead to a 304 — saving bandwidth but not the round trip.
These lose points
- A long
max-ageon HTML. Users get stuck on an old build and you have no way to push a new one.