Practical HTTP caching interview answer for frontend engineers: cache directives, validators, conditional requests, and deployment-safe caching strategy for HTML, APIs, and immutable static assets.
HTTP Caching in Frontend: Cache-Control, ETag, Last-Modified, and 304
Preparing for interviews?
Use guided tracks for structured prep, then practice company-specific question sets when you want targeted interview coverage.
Quick Answer
Answer
Definition (above the fold)
HTTP caching is the policy layer that decides whether the browser can reuse a response, must revalidate it, or must fetch a new one. A complete answer covers freshness (Cache-Control), validation (ETag/Last-Modified), and revalidation result (304 with no body).
Core mental model
Use this sequence: (1) Is cached response fresh? If yes, serve locally. (2) If stale, send conditional request with validators. (3) Server returns 304 (reuse cached body) or 200 (replace cache entry).
Directive | What it means | Typical use |
|---|---|---|
| Response is fresh for N seconds | Static assets and read-heavy APIs |
| Store allowed but must revalidate before use | HTML documents with frequent updates |
| Do not persist at all | Sensitive or user-private payloads |
| No revalidation during freshness window | Versioned static files |
| Shared cache allowed or browser-only | Shared CDN vs user-specific responses |
Runnable example #1: cache headers by response class
HTTP
# versioned JS/CSS bundle
Cache-Control: public, max-age=31536000, immutable
# API response with revalidation
Cache-Control: public, max-age=30, stale-while-revalidate=60
ETag: "products-v241"
# user profile
Cache-Control: private, no-store
This pattern avoids stale sensitive data while keeping static assets extremely fast on repeat visits.
Runnable example #2: conditional request lifecycle
HTTP
GET /api/products HTTP/1.1
If-None-Match: "products-v241"
HTTP/1.1 304 Not Modified
Cache-Control: public, max-age=30
ETag: "products-v241"
Validator | Strength | When to prefer |
|---|---|---|
ETag | High precision content validator | When you can generate stable content versions |
Last-Modified | Timestamp-based validator | Simple systems with coarse change cadence |
Both together | Fallback compatibility | Broad client/proxy environments |
Common pitfalls
- Using long cache TTL for HTML without versioning/revalidation strategy.
- Forgetting
Varysemantics (for example gzip/language/auth differences) and serving wrong cached variants. - Treating 304 as success without understanding it has no response body.
- Applying one policy to all endpoints instead of resource-specific rules.
When to use / when not to use
Use aggressive immutable caching for fingerprinted assets and conservative revalidation for mutable APIs/HTML. Use no-store for truly sensitive responses. Avoid disabling caching globally; it often harms performance and increases infrastructure cost with no security gain.
Interview follow-ups
Q1: What does a 304 body contain? A: No body; browser reuses cached entity body.
Q2: Why is ETag often preferred? A: Better precision than timestamps for detecting content changes.
Q3: First caching win in production? A: Immutable versioned static assets plus short revalidation for HTML/API.
Implementation checklist / takeaway
Classify resources, set explicit cache directives, attach validators for mutable content, and verify behavior with network traces. Strong answers show both protocol mechanics and deployment-safe strategy.
Similar questions
Guides