Mastering HTTP Caching: How Browsers Store and Reuse Web Resources

Introduction

HTTP caching is an essential web performance optimization technique that every front‑end developer should understand. It explains why resources are cached and how the cache becomes effective.

Before diving into HTTP caching, we briefly review the structure of an HTTP message.

An HTTP message is the data exchanged between a browser and a server. The browser sends a request message; the server returns a response message. Each message consists of two parts: a header (metadata such as cookies and cache directives) and a body (the actual payload).

Cache Rules Overview

We treat the browser as having a cache database that stores cached entries.

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 major categories: strong (forced) caching and validation (conditional) caching.

Below are sequence diagrams illustrating each rule.

Strong caching flow when a cached entry exists:

Validation caching flow when a cached entry exists:

Strong Caching

When a cached entry has not expired, the browser can use it directly. The server provides cache directives in the response headers.

Two header fields control expiration: Expires and Cache‑Control.

Expires

The Expires value is a timestamp returned by the server; if the current request time is earlier than this timestamp, the cached copy is used. This header belongs to HTTP/1.0 and is largely ignored by modern browsers.

Cache‑Control

Cache‑Control

is the most important directive. Common values are private, public, no-cache, max-age, and no-store. The default is private.

private:          client can cache
public:           client and proxy can cache
max-age=xxx:      cached content expires after xxx seconds
no-cache:         must revalidate with the server
no-store:         nothing is cached (rarely used in front‑end)

In the illustration, only max-age is set, so the default private applies and the cache lives for 31536000 seconds (one year).

Validation Caching

Validation caching requires the browser to compare a validator with the server before using the cached copy.

On the first request, the server returns the resource together with a validator (e.g., Last‑Modified or ETag) and stores both in the cache.

On subsequent requests, the browser sends the validator in the request headers. If the server determines the resource is unchanged, it responds with status 304 and no body, allowing the browser to reuse the cached copy.

Last‑Modified / If‑Modified‑Since

Last‑Modified: The server tells the browser the last modification time of the resource.

If‑Modified‑Since: The browser sends this timestamp on a later request. The server compares it with the current modification time; if the resource has changed, it returns 200 with the full body, otherwise it returns 304.

ETag / If‑None‑Match (higher priority)

ETag: The server provides a unique identifier for the current version of the resource.

If‑None‑Match: The browser sends the previously received ETag. If the identifiers match, the server returns 304; otherwise it returns 200 with the new content.

Summary

Strong caching lets the server specify a max‑age; within that period the browser uses the cached copy without contacting the server. Validation caching sends validators (ETag, Last‑Modified) on each request; the server replies with 304 when the resource is unchanged, allowing the browser to reuse the cache.

First request flow:

Subsequent request flow:

Requests That Cannot Be Cached

Responses with Cache‑Control: no-cache, pragma: no-cache, or Cache‑Control: max-age=0.

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

HTTPS requests (unless specially 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 cache headers to static assets (CSS, JS, images) and set a long expiration; avoid caching the entry HTML page.

Minimize cookie usage to reduce request size and improve cacheability.

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

Prefer GET over POST for idempotent requests to enable caching.

Cache dynamic scripts by periodically generating static files with proper Last‑Modified / ETag headers, or by adding Cache‑Control: max-age in the response.

How to Add Caching to Your Site

As a front‑end developer, you generally do not need to modify code, but you should coordinate with web operations and back‑end developers to ensure appropriate cache headers are set on both static files and dynamic scripts.