How does browser caching work?
Browser caching is a mechanism by which a web browser stores copies of HTTP responses locally, reusing them for subsequent requests to avoid unnecessary network round-trips. The behavior is entirely controlled by HTTP response headers set by the server.
The primary control header is **Cache-Control**. The `max-age=N` directive tells the browser the resource is fresh for N seconds and can be served from the local cache without contacting the server — this is called a **strong cache hit** and has zero network overhead. Common directives include `no-cache` (must revalidate with the server before using the cached copy — despite the name, the response is still cached), `no-store` (do not cache at all), `public` (CDNs and proxies may also cache it), and `private` (only the end-user's browser may cache it, not intermediate proxies).
The older **Expires** header specifies an absolute date/time for expiry, but it has fallen out of favor because it requires synchronized clocks and is less flexible than `Cache-Control max-age`.
When a cached resource expires, the browser performs a **conditional request** using revalidation headers rather than fetching the full resource. Two mechanisms exist: - **ETag** / **If-None-Match**: The server assigns an opaque token (typically a hash of the content) to the response. On revalidation, the browser sends `If-None-Match: <etag>`. If the content hasn't changed, the server responds `304 Not Modified` with no body — saving bandwidth while confirming freshness. - **Last-Modified** / **If-Modified-Since**: The server sends the resource's last modification date; the browser echoes it back on revalidation. Less reliable than ETags for byte-identical detection.
For **cache busting** with immutable assets (JavaScript bundles, CSS), the best practice is content-addressed filenames (e.g., `main.a3f9c2.js`) combined with `Cache-Control: max-age=31536000, immutable`. The `immutable` directive tells the browser not to revalidate even on manual refresh, eliminating conditional requests for assets that will never change at a given URL. When the content changes, the filename hash changes, forcing a fresh fetch.
Service Workers add a programmable caching layer that intercepts all fetch events, enabling offline-first strategies, background sync, and fine-grained cache invalidation beyond what HTTP headers alone provide.
Correctly explains Cache-Control max-age for strong caching and ETag/304 for revalidation. May not distinguish no-cache vs. no-store or mention cache busting strategies.
Covers Cache-Control directives precisely (including the no-cache misnaming trap), explains both ETag and Last-Modified revalidation, describes the immutable + content hash pattern for static assets, and mentions Service Workers as a programmatic caching layer.
Reading the answer is step one. Explaining it unprompted — under interview pressure — is what actually matters. Get AI-graded feedback on your answer with follow-up probes on your weak points.
Get Graded — Free Assessment