FrontendHaltHTTP caching
Control freshness and revalidation with Cache-Control, validators, shared caches, and versioned assets.
WHAT YOU WILL BE ABLE TO DO
Learning outcomes
- Explain http caching in plain language.
- Connect the behavior to the underlying browser or framework model.
- Implement the core pattern and reason through edge cases.
- Answer common follow-ups without relying on memorized phrases.
01Explain it simply
HTTP caching lets a browser or CDN reuse a response instead of downloading it again. The server describes how long the response stays fresh and how to validate it after it becomes stale.
One-line definition: Control freshness and revalidation with Cache-Control, validators, shared caches, and versioned assets.
02Mental model
Fresh responses are reused without contacting the origin. Stale responses can be revalidated using ETag/If-None-Match or Last-Modified/If-Modified-Since; a 304 response confirms the cached body is still valid.
03Step by step
- Classify the response as public, private, or uncacheable.
- Choose a freshness lifetime.
- Add a validator for revalidation.
- Use content hashes for immutable static assets.
- Include Vary when representation changes by request header.
04Working example
# Versioned JavaScript bundleCache-Control: public, max-age=31536000, immutable
# HTML documentCache-Control: no-cacheETag: "page-v42"A hashed bundle can be cached for a year because a content change produces a new URL. HTML uses no-cache so it may be stored but must revalidate before reuse.
05Where it is used
- Static assets and fonts
- CDN edge caching
- API response revalidation
- Offline-tolerant navigation
06Common mistakes
- Confusing no-cache with no-store
- Long-caching unversioned HTML
- Caching personalized responses in a shared cache
- Forgetting Vary and serving the wrong representation
07Interview answer
Distinguish freshness from storage permission and revalidation. Give separate policies for immutable assets, HTML, and personalized API responses.
What is the difference between no-cache and no-store?
no-cache allows storage but requires revalidation before reuse; no-store instructs caches not to store the response.
DDConcept deep dives
Deep dive 1
A cache needs a reusable representation and policy
Browsers, service workers, proxies, and CDNs can store responses at different layers. Cache-Control describes storage permission, freshness lifetime, revalidation, and shared-cache behavior. The correct policy depends on whether a response is versioned, personalized, safe to share, and tolerant of staleness.
- public and private concern shared-cache eligibility, not whether data is secret.
- no-store prevents storage; no-cache permits storage but requires validation.
- Authorization and cookies require deliberate shared-cache rules.
Deep dive 2
Validators avoid retransmitting unchanged bodies
After freshness expires, a cache can send If-None-Match with an ETag or If-Modified-Since with a date validator. A 304 response confirms the stored body remains valid and transfers only response metadata. Strong and weak validators make different equivalence promises.
- ETags should remain stable for the same selected representation.
- Vary makes selecting request headers part of cache lookup.
- A revalidated response still incurs network latency even when its body is reused.
Deep dive 3
Versioned assets separate change from freshness
A content hash in an asset URL means changed bytes produce a new URL. That makes a long max-age plus immutable safe: an old page can still request its old compatible bundle, while new HTML references new assets. The HTML itself must revalidate frequently enough to discover the new names.
- Never long-cache unversioned HTML as immutable.
- Keep previous hashed assets available during a deployment window.
- Design APIs for old open tabs because client updates are not atomic.
QAInterview questions and model answers
Attempt each answer aloud before opening it. The model answer shows the depth and precision expected in an interview; it is not a script to memorize.
Intermediate · Conceptual · 1 min · Question 1What is the difference between freshness and validation?Open model answer
Model answer
A fresh cached response can be reused without contacting the origin. A stale response may be conditionally revalidated with an ETag or Last-Modified validator; a 304 confirms the stored representation remains usable.
Open question page →Intermediate · Conceptual · 1 min · Question 2How do no-cache and no-store differ?Open model answer
Model answer
no-cache permits storage but requires successful revalidation before reuse. no-store asks caches not to store the response. Sensitive responses may need no-store, while frequently changing HTML often benefits from no-cache plus validators.
Open question page →Intermediate · Conceptual · 1 min · Question 3Why use immutable caching with hashed assets?Open model answer
Model answer
A content hash changes the URL whenever bytes change, so the old URL can safely receive a long max-age and immutable directive. HTML should not be long-cached under an unversioned URL because it must discover new asset names.
Open question page →Intermediate · Conceptual · 1 min · Question 4What does Vary do?Open model answer
Model answer
It tells caches which request headers helped select the representation, making them part of the cache key. Missing Vary can serve the wrong encoding or origin-specific response; excessive Vary fragments the cache.
Open question page →Intermediate · Conceptual · 1 min · Question 5What is the difference between private and public?Open model answer
Model answer
private prevents storage by shared caches while still allowing a browser cache; public explicitly permits shared caching where other rules allow it. Authorization and Set-Cookie interactions require deliberate policies rather than assumptions.
Open question page →Intermediate · Conceptual · 1 min · Question 6How does stale-while-revalidate help?Open model answer
Model answer
It permits serving a stale response within a defined window while revalidation happens in the background, improving latency at the cost of bounded staleness. It suits data where that trade-off is acceptable.
Open question page →Advanced · Conceptual · 1 min · Question 7What is s-maxage?Open model answer
Model answer
It sets freshness for shared caches and overrides max-age there while browsers continue using the ordinary cache lifetime. It is useful for CDN-specific policy.
Open question page →Advanced · Conceptual · 1 min · Question 8What does must-revalidate mean?Open model answer
Model answer
Once a response becomes stale, a cache must successfully validate it before reuse rather than serving it stale during origin unavailability unless another directive permits that behavior.
Open question page →Advanced · Conceptual · 1 min · Question 9Why can Vary: Cookie destroy cache efficiency?Open model answer
Model answer
It can create a distinct representation key for many cookie values, fragmenting a shared cache. Prefer separating personalized and public resources or varying on narrow signals.
Open question page →Advanced · Conceptual · 1 min · Question 10Who chooses whether a 304 body is reused?Open model answer
Model answer
The cache sends a conditional request, receives metadata-only 304, updates stored metadata as required, and serves its existing representation body to the consumer.
Open question page →SCScenario questions
Scenario 1
After deployment, some users keep loading old JavaScript that no longer matches the HTML API.
- Inspect cache headers on HTML and assets separately.
- Ensure assets use content-hashed filenames.
- Make HTML revalidate instead of long-caching it immutably.
- Design backward-compatible deployment boundaries.
Reveal worked answer
The likely error is applying a long immutable policy to unversioned HTML or JavaScript. I would serve hashed assets with long immutable caching and HTML with revalidation. Deployment should also tolerate old clients briefly because caches and open tabs cannot be made perfectly atomic.