Mastering Browser Caching: Strong vs. Conditional Cache Explained

Introduction

Browser cache stores resources on the client side to speed up page loads and reduce redundant network requests, thereby improving user experience.

1. Strong Cache

1.1 Distinguishing Expires and Cache‑Control

Expires is an HTTP/1.0 header that specifies an absolute expiration time. Modern browsers default to HTTP/1.1, so its impact is limited, and it can be inaccurate when client and server clocks differ.

Cache‑Control is an HTTP/1.1 header that uses relative time (e.g., max-age=2552). When both headers appear, Cache‑Control takes precedence.

Common Cache‑Control directives:

no-cache : cache may be used but must be revalidated with the server.

no-store : disables caching entirely.

public : allows shared caches to store the response.

private : only the client may cache the response.

max-age : maximum lifetime in seconds.

min-fresh : client accepts responses that will become stale within the specified time.

max-stale : client accepts responses that are stale up to the specified limit.

Note: no-cache does not mean “no cache”; it means the cached entry must be validated before use. no-store truly disables caching.

1.2 Strong Cache Process

Browser requests a resource; the server returns the resource together with Expires and/or Cache‑Control headers.

On subsequent requests, the browser checks the local cache. If the cached entry is still within the validity period (based on Expires or max‑age), it serves the resource from cache without contacting the server.

If the entry is expired, the browser sends a new request to the server.

The response headers are refreshed on each reload.

Typical status codes for strong cache hits are 200 OK (from disk cache) or 200 OK (from memory cache).

2. Conditional Cache

2.1 Last‑Modified and If‑Modified‑Since

When a server includes a Last‑Modified header (e.g., Mon, 17 Sep 2018 12:06:18 GMT), the client can later send If‑Modified‑Since with the same timestamp. If the resource has not changed, the server replies 304 Not Modified, and the client uses the cached copy.

2.2 What Is an ETag?

The server generates an ETag value that uniquely identifies the current version of a resource (often a hash of inode, size, and modification time). This value is returned in the response header.

2.3 Conditional Cache Process

First request: server returns the resource with Last‑Modified and/or ETag headers.

Subsequent request: client sends If‑Modified‑Since (using the previous Last‑Modified) and/or If‑None‑Match (using the previous ETag).

Server compares the sent values with the current resource state.

If unchanged, it returns 304 Not Modified and the client loads from cache.

If changed, it returns 200 OK with the new content (and a new ETag if applicable).

2.4 Why Use ETag in Addition to Last‑Modified?

Some files change frequently but their content remains the same; Last‑Modified would falsely indicate a change.

File modifications can occur within sub‑second intervals, which Last‑Modified (second precision) cannot capture.

Certain servers cannot reliably obtain the exact modification timestamp.

ETag provides a precise, server‑generated identifier that changes whenever the resource changes, allowing more accurate cache validation. When both are present, servers typically prioritize ETag validation.

2.5 Comparing Strong and Conditional Cache

Both mechanisms aim to reduce unnecessary network traffic, but they differ in validation strategy. Strong cache relies solely on expiration information, while conditional cache uses validation headers ( Last‑Modified / If‑Modified‑Since and ETag / If‑None‑Match) to confirm freshness before re‑downloading.

Conclusion

The article uses diagrams to illustrate HTTP caching, covering both strong and conditional cache mechanisms, their headers, directives, workflows, and differences, providing developers with a clear reference for optimizing web performance.