HTTP Caching for Frontend: Cache-Control, ETag, and Practical Strategies

Caching is one of the biggest performance levers. Interviews ask about it because it’s easy to talk about but hard to get right.

This guide focuses on the practical pieces frontend engineers should know.

30‑second interview answer

HTTP caching is controlled mainly by Cache-Control plus validators like ETag/If-None-Match and Last-Modified/If-Modified-Since. You choose between freshness caching (serve from cache until max-age) and revalidation (use validators to get 304). Use long cache for versioned static assets, and revalidate or no-store for user-specific/sensitive data.

Key points

• max-age = freshness; no-cache = store but revalidate; no-store = don’t store.
• ETag + If-None-Match enables 304 responses.
• Use s-maxage for CDN/shared caches.
• Cache static assets aggressively with fingerprinting.

1) The 3 layers of caching (mental model)

1. Browser cache (your device)
2. CDN / edge cache (near user)
3. Server / app cache (backend)

HTTP headers control (1) and (2) heavily.

2) Cache-Control (the main header)

Common directives:

• max-age=... — how long it can be used (seconds)
• public — can be cached by shared caches (CDNs)
• private — only browser cache
• no-store — don’t store at all
• no-cache — can store but must revalidate
• s-maxage — max-age for shared caches
• stale-while-revalidate — serve stale while fetching fresh

Example for static assets:

Cache-Control: public, max-age=31536000, immutable

Example for HTML pages (often):

Cache-Control: no-cache

3) Validation caching: ETag + If-None-Match

ETag is a version identifier for a resource.

Flow:

1. Server responds with ETag: "abc"
2. Next request sends If-None-Match: "abc"
3. If unchanged → server returns 304 Not Modified

This saves bandwidth.

4) Last-Modified + If-Modified-Since

Similar idea, based on timestamps. Less precise than ETag.

5) CDN caching vs user-specific data

A classic production bug is caching personalized responses.

Rule:

• Never cache user-specific API responses as public.

Use:

• Cache-Control: private for user-specific responses
• Vary: Authorization or Vary: Cookie when needed

6) Frontend strategy: what to cache

Cache aggressively

• JS/CSS bundles with content hashes
• images
• fonts

Be careful

• HTML shell (depends on SSR/ISR strategy)
• API responses (depends on privacy)

In SPAs, app-level caching often uses:

• React Query / SWR
• service worker caches

7) Interview Q&A

Q: no-cache vs no-store?

• no-store: don’t store at all.
• no-cache: may store but must revalidate.

Q: What does immutable mean?

• resource won’t change during max-age (good for hashed assets).

Q: Why use ETag?

• validation caching to return 304 and save bandwidth.

Summary checklist

• I can explain freshness vs validation caching.
• I can explain no-store vs no-cache.
• I know how ETag enables 304.
• I can describe caching strategy for hashed assets.

Summary

• Cache-Control is the main tool.
• ETag enables 304 validation caching.
• Cache static assets aggressively (hashed + immutable).
• Never accidentally cache personalized responses at CDN.