ETag vs Cache-Control
Slap yourself if
You think ETag and Cache-Control solve the same problem or believe ETags are just a stronger form of caching.
Why this exists
Because many systems misuse ETags to paper over poor cache policy, accidentally introduce latency, and ship inconsistent behavior across CDNs, browsers, and service workers.
Mental model
Cache-Control decides if a request happens. ETag decides if a response payload changes. One is about time and permission, the other about identity and validation.
- Cache-Control determines whether a cached response can be reused without contacting the server.
- ETag enables conditional requests to validate cached content with the origin.
- A revalidation request still incurs network latency even if the payload is unchanged.
- Different cache layers may interpret or ignore ETags differently.
- Using ETag instead of setting proper Cache-Control headers.
- Assuming 304 responses are free.
- Breaking CDN caching with per-user ETags.
- Expecting Service Workers to honor HTTP validation automatically.
Cache-Control governs cache reuse and freshness, while ETag supports conditional validation when a request must recheck with the server.
- Says ETag is better than Cache-Control.
- Treats 304 as zero-cost.
- Ignores intermediary caches.
- Assumes browser-only behavior.
Deep dive
Requires Pro
Premium deep dives include more internals, more scars.