Master Browser Caching: Boost Web Performance with Strong & Negotiated Caches

Browser Caching

First, understand caching with a diagram:

Why Cache?

From a performance perspective, caching reduces latency and network congestion by reusing existing resources, thereby shortening the time needed to display a resource.

Purpose of Caching

Caching enables reuse of resources, reduces delay and network blockage, and speeds up resource presentation. For web pages, the two main requirements are static resource loading speed and page rendering speed.

Rendering speed depends on loading speed, and the order and timing of different resource types affect it, giving caching a large optimization space.

Typical Caching Scenarios

Repeatedly loading the same static file wastes bandwidth; use browser local cache (negotiated cache, 304 response).

Negotiated cache still requires a server request; use strong cache (200 response) to avoid network traffic.

When resources need updating, use ETag headers or versioned URLs (e.g., hash in filename) to signal changes.

Deploy static assets to CDN nodes and reference them via CDN URLs; decide deployment order (static assets vs. pages) based on release strategy.

For internationalized products, use non‑overwriting releases: rename files with a hash of their content, deploy static assets first, then roll out pages gradually.

Types of Cache

Data Cache

Cookie : Stores small pieces of data (up to ~4 KB) on the client. The server sends a Set‑Cookie header; the browser returns the cookie on subsequent requests, allowing the server to identify the user.

Session : Stored on the server. The browser sends a session‑id cookie; the server uses it to retrieve session data. If a request lacks a session‑id, the server creates a new session and returns the id.

Common cookie attributes:

Expires – maximum lifetime of the cookie.

Max‑Age – seconds until expiration (takes precedence over Expires when both are present).

Domain – hostnames to which the cookie may be sent.

Path – URL path that must be present for the cookie to be sent.

Secure – cookie is sent only over HTTPS.

HttpOnly – prevents JavaScript access, mitigating XSS attacks.

Storage

sessionStorage : Stores data for the lifetime of a page session; cleared when the page is closed. Data is stored in plain text and can include arrays, images, JSON, etc.

localStorage : Persists data even after the browser is closed; also stored in plain text. Both have a typical quota of about 5 MB.

Both can be monitored via the

storage

event on the

window

object, which provides

key

,

oldValue

,

newValue

,

url

, and

storageArea

properties.

HTTP Header Cache

Effective caching reduces redundant resource loading and improves page load speed. HTTP caching is divided into strong cache and negotiated cache.

Basic Overview

When a browser loads a resource, it first checks the

Expires

and

Cache‑Control

response headers for a strong cache. If none is found, it sends a request and uses

Last‑Modified

or

ETag

to perform negotiated caching, receiving a 304 response when the resource is unchanged.

Strong Cache

Defined by

Expires

(absolute GMT time) and

Cache‑Control: max‑age

(relative seconds). When both are present,

max‑age

takes precedence.

Cache‑Control Directives

no-cache : Forces validation with the server before using cached data.

no-store : Prevents any caching; the resource is fetched on every request.

public : Allows any cache (browsers, CDNs) to store the response.

private : Restricts caching to the end‑user’s browser only.

When both

Cache‑Control

and

Expires

are set,

Cache‑Control

has higher priority.

Negotiated Cache

Relies on server‑side validation using

ETag

/

If‑None‑Match

and

Last‑Modified

/

If‑Modified‑Since

headers. The server returns a 304 Not Modified response when the resource has not changed.

Cache Flow Diagram

Further caching topics will be explored in future articles.