HTTP Caching

When a web page loads, the browser downloads dozens to hundreds of assets. Logo images, font files, and library bundles do not change between visits, yet downloading the same files from the server every time wastes time and piles unnecessary load on the server. Conversely, caching too aggressively means that after a deployment, users may keep receiving outdated files instead of the updated ones. Using no caching at all or failing to control it properly forces an unnecessary tradeoff between performance and freshness.

The early HTTP specification had a loose definition of caching. Approaches like the Expires header that used absolute dates and times led to unpredictable behavior when client and server clocks were out of sync. HTTP/1.1 introduced the Cache-Control header, unifying fine-grained directives such as relative freshness (max-age), shared cache control (s-maxage), and no-cache/no-store into a single header. ETag and conditional GET were then added, establishing the revalidation pattern of 'even if the cache has expired, do not retransmit the body if the actual content has not changed'. Today, with CDNs serving as the foundation of global distribution, cache lifetime management through Cache-Control has become the first tool of performance optimization.

When the browser requests a resource, it first checks the cache. If a stored response exists and falls within its max-age, it is returned immediately without touching the network. If stored but past its max-age, the browser sends a conditional request carrying an If-None-Match (ETag value) or If-Modified-Since header. If the actual content has not changed, the server returns only a 304 Not Modified with no body, and the browser continues using the existing cache while refreshing its validity period. If there is no cache at all or a no-store directive is present, the full response is fetched every time. Cache-Control: no-cache -- despite its name -- does not mean 'do not use caching' but rather 'always revalidate before using'.

HTTP caching and Service Worker caching both aim to reduce network requests and speed up responses, but they operate at different layers and are controlled by different parties. HTTP caching is infrastructure-level caching handled automatically by the browser and the HTTP spec. Set Cache-Control header values and the browser or CDN acts accordingly. Service Worker caching is programmatic caching written directly in JavaScript by the developer. Because the developer decides in code which requests to intercept, which responses to store where, and when to retrieve them, it can handle scenarios that HTTP headers alone cannot -- like offline support, request interception, and dynamic cache strategies. It is common to use HTTP caching for baseline performance and add a Service Worker when more granular offline or strategic needs arise. SSG (Static Site Generation) and HTTP caching operate at different layers but connect naturally. Because SSG produces HTML at build time, responses become static files, and static files are the easiest form to cache in CDNs and browsers. Using hash-based filenames (e.g., main.a1b2c3.js) means the URL itself changes on update, so setting max-age to a year while simultaneously solving cache invalidation on deployment is possible.

To effectively leverage HTTP caching in practice, strategies must be split by resource type. JS, CSS, and images whose bundle filenames include content hashes can safely be cached for a year with Cache-Control: public, max-age=31536000, immutable. HTML documents and API responses with fixed URLs should use no-cache or a short max-age to always verify freshness. When using a CDN, manage edge cache lifetime independently from browser cache with s-maxage, and automate CDN invalidation (cache purge) alongside deployments to prevent stale responses from lingering at the edge. Most caching problems arise from either 'not setting Cache-Control at all' or 'serving different content at the same URL while forgetting to invalidate'. If a new feature is released but some users still see the old screen, checking the cache policy and deployment pipeline together should be the first step.