Architecture Guide to HTTP Caching & Edge CDNs
Properly configuring HTTP caching headers is one of the highest leverage performance and cost-saving optimizations in cloud architecture. By offloading static assets, API responses, and dynamic SSR pages to Content Delivery Networks (CDNs) like Cloudflare, AWS CloudFront, and Fastly, origin compute load can be reduced by 70% to 95%.
Key Cache-Control Directives Explained
max-age vs s-maxage:max-ageinstructs the end-user's browser how long to store the response locally;s-maxageoverrides this exclusively for shared public proxies and CDN edge servers.stale-while-revalidate (RFC 5861):Instructs the CDN/browser to immediately return an expired cached copy to the client (sub-10ms response time) while asynchronously fetching an updated representation from the origin in the background.immutable:Informs browsers that the asset body will never change over time. When used with content-hashed filenames (e.g.bundle.a8f9c2.js), browsers completely bypass revalidation requests during page reloads.no-cache vs no-store:no-cacheallows storing the response but forces the browser to validate its freshness viaIf-None-Match (ETag)before reuse;no-storeforbids caching entirely on any disk or memory cache.
The Critical Role of the Vary Header
Whenever an endpoint serves different responses based on request headers (such as compression algorithms with Vary: Accept-Encoding or localized content with Vary: Accept-Language), the Vary header must be explicitly sent to prevent CDNs from serving compressed gzip payloads to clients that cannot decompress them.