Day 20: HTTP caching & compression
Not sending data is always faster than sending it well
HTTP caching lets a client (or an intermediary like a CDN, Day 23) skip the request entirely when it already has a valid copy.
Cache-Control: max-age=3600— reuse this response for up to an hour without asking againETag— a fingerprint of the response body; the client can send it back (If-None-Match) and get a cheap 304 Not Modified if unchangedCache-Control: no-store— never cache this at all (common for sensitive/personalized responses)
The same TTL trade-off as DNS
A long max-age is efficient but means stale content lingers if the underlying data changes. This is the exact same speed-vs-freshness trade-off as DNS TTL (Day 18) — the same tension shows up again with Redis cache invalidation in Phase 16.
Compression
A client advertises what it can decode (Accept-Encoding: gzip, br); the server compresses the response body before sending, and the client decompresses on arrival. Trading a small amount of CPU time (to compress/decompress) for a large reduction in bytes over the network — usually a clear win, since the network is almost always the slower resource.
Key terms
- Cache-Control
- An HTTP header controlling whether/how long a response may be cached.
- ETag
- A fingerprint of a response body used to cheaply check "has this changed?" without re-sending it.
- gzip / br (Brotli)
- Compression encodings negotiated via Accept-Encoding to shrink response bodies in transit.
A response returns 304 Not Modified after the client sends If-None-Match. What just happened?
