Mastering HTTP Caching: How Browsers Store and Reuse Web Resources

Introduction

HTTP caching is a crucial web performance optimization technique that every front‑end developer should master. It explains why browsers cache resources, how the cache works, and how to use it effectively.

HTTP Message Basics

An HTTP message is the data block exchanged between a browser and a server. The browser sends a request message, and the server returns a response message. Each message consists of two parts:

Header : contains metadata such as cookies, cache directives, and other control information.

Body : the actual payload of the request or response.

Cache Rule Overview

We can think of the browser as having a cache database that stores cached resources. On the first request, the cache is empty, so the browser fetches the resource from the server and stores it. HTTP caching rules are divided into two categories: strong cache and validation (comparison) cache.

Strong Cache

When a cached entry is still valid, the browser can use it directly without contacting the server. The server indicates the cache lifetime via response headers (Expires or Cache-Control).

Expires

The Expires header contains an absolute expiration date. If the current request time is earlier than this date, the cached response is used. Expires is part of HTTP/1.0 and is largely ignored by modern browsers.

Cache-Control

Cache-Control is the primary directive in HTTP/1.1. Common values include private, public, no-cache, max-age, and no-store. The default is private.

private: client can cache<br/>public: client and proxy can cache (frontend can treat as the same)<br/>max-age=xxx: cache expires after xxx seconds<br/>no-cache: must use validation cache<br/>no-store: no caching at all, both strong and validation are disabled

In the example image, only max-age is set, so the default private applies and the cache lasts 31536000 seconds (365 days).

Validation (Comparison) Cache

Validation cache requires the browser to send a conditional request to the server. The server compares the cached identifier with the current resource and, if unchanged, returns a 304 Not Modified status, allowing the browser to reuse the cached body.

Last-Modified / If-Modified-Since

The server includes the resource's last modification time in the Last-Modified header. On subsequent requests, the browser sends If-Modified-Since. If the resource has not changed, the server replies with 304; otherwise it returns the full content with 200.

Etag / If-None-Match

The server provides a unique identifier for the resource in the Etag header. The browser sends this value back in If-None-Match. If the identifier matches, the server returns 304; otherwise it returns the fresh content with 200. Etag has higher priority than Last-Modified.

Summary

Strong cache relies on a server‑provided expiration time; within that period the browser serves the cached response directly. Validation cache sends conditional headers (Etag, Last-Modified) and uses a 304 response to confirm that the cached copy is still valid.

Requests That Cannot Be Cached

Requests with Cache-Control: no-cache, Pragma: no-cache, or Cache-Control: max-age=0 in the response header.

Dynamic requests that depend on cookies, authentication, or other user‑specific data.

HTTPS requests are generally not cached unless special headers are configured.

POST requests.

Responses that lack Last-Modified, Etag, Cache-Control, or Expires headers.

Practical Applications

Keep resource URLs stable so browsers can reuse cached copies across pages.

Add appropriate cache headers to static assets (CSS, JS, images) and prevent caching of entry HTML files.

Minimize cookie usage to reduce request size and improve cacheability.

Prefer HTTPS only for sensitive data; serve static assets over HTTP when possible.

Use GET instead of POST for idempotent requests to enable caching.

For dynamic scripts, periodically generate static files with Last-Modified or Etag headers, or set Cache-Control: max-age manually.

How to Enable Caching for a Site

As a front‑end developer, you typically do not need to modify code directly; instead, coordinate with web operations and back‑end teams to ensure that servers and dynamic scripts send proper cache headers.