HTTP caching control

Enables browsers and CDNs to skip redundant network fetches by declaring how long and under what conditions a response may be reused.

Web development: serving versioned static assets (CSS, JS, images) from a CDN with long max-age API design: distinguishing cacheable public GETs from personalized responses with Cache-Control: private, no-store Performance optimization: enabling conditional 304 revalidation via ETag or Last-Modified to avoid resending bodies

HTTP servers, CDN configuration (Cloudflare, Fastly, Akamai), REST APIs, static site generators, reverse proxies (nginx, Varnish, Squid), web frameworks (Express, Django, Rails, Spring)

set Cache-Control: <directive> on response → browser/proxy caches per directive → conditional revalidation via ETag or Last-Modified

• Cache-Control
• ETag
• Last-Modified
• Expires
• Vary
• max-age
• no-cache
• no-store
• private
• public
• s-maxage
• If-None-Match
• If-Modified-Since
• 304 Not Modified
• immutable
• stale-while-revalidate

• ETag vs Last-Modified: ETag uses opaque tokens for exact-match revalidation (heavier but precise)
• Last-Modified uses timestamps with second resolution (cheaper but coarse). Cache-Control: max-age vs Expires: max-age is HTTP/1.1 relative time and preferred
• Expires is HTTP/1.0 absolute date and legacy.

Setting Cache-Control: public on personalized responses → caches user-specific data and leaks it to other users. Omitting Vary: Accept-Encoding when serving gzipped assets → compressed content served to clients that cannot decode it. Using max-age=0, no-cache thinking it disables caching → it actually permits storage but forces revalidation on every request. Forgetting to invalidate caches after deployment → users see stale JS/CSS until natural expiry. Setting Expires in the past → browsers evict the resource instead of caching it.

ETag vs Last-Modified: ETag is an opaque validator token; Last-Modified is a timestamp with second precision. Cache-Control vs Expires: Cache-Control is HTTP/1.1 with relative seconds; Expires is HTTP/1.0 with absolute dates. Pragma: no-cache vs Cache-Control: no-cache: Pragma is HTTP/1.0 legacy and unreliable for proxies; Cache-Control is the modern authoritative directive.

Coming from Python/Flask: may assume Flask auto-sets caching headers — Flask defaults to no caching, so Cache-Control must be set explicitly per response. Coming from PHP: may rely on session-based cache busting without setting Cache-Control — PHP's default response headers often prevent caching entirely. Coming from static-site generators: may emit identical filenames across builds — without content hashing, long max-age caches will serve stale assets forever.

• HTTP caching
• ETag
• Last-Modified
• Cache-Control directives
• conditional requests
• CDN caching
• cache invalidation

When NOT to use: never cache responses containing user-specific or authenticated data without Cache-Control: private or no-store. Performance: aggressive caching can cut origin load by 80%+ and shave seconds off repeat-visit TTFB, but requires cache-busting (filename hashing, query strings) for updates. Boundary: intermediate proxies (CDNs, corporate gateways) may ignore headers unless Cache-Control: public or s-maxage is specified; private responses bypass shared caches entirely.

Properly configured caching headers can reduce origin server load by 80%+ and improve repeat-visit page load from seconds to milliseconds, directly impacting Core Web Vitals (LCP, INP), CDN egress costs, and perceived performance.

Caching headers are like a librarian's stamp on a book — they tell every future visitor how long the book is 'current' and whether they need to check the catalog again before reading it.

Cache invalidation strategies (purge APIs, stale-while-revalidate, surrogate-keys, content-hash filenames)