Mastering Browser Caching: HTTP, Cookies, LocalStorage, and IndexedDB Explained

Client‑side caching includes HTTP caching and local caching, offering benefits such as reduced duplicate data transfer, bandwidth savings, and lower server load.

HTTP Cache

HTTP caching consists of strong (forced) caching and conditional (negotiated) caching. It is used to store static resources like images, CSS, and JavaScript that rarely change.

Strong Cache

When a browser requests a resource, it first checks the response headers for Cache‑Control or Expires directives. If a strong cache hit occurs, the resource is served from the cache without contacting the server.

Cache directives

Expires : expiration time in the response header; resources are considered fresh until this time.

Cache‑Control : e.g., max-age=300 means the resource is fresh for 5 minutes.

When both Cache‑Control and Expires are present, Cache‑Control takes precedence.

Common directives include public, private, no-cache, no-store, no-transform, must-revalidate, proxy-revalidate, max-age, min-fresh, max-stale, etc.

Conditional Cache

If a strong cache miss occurs, the browser sends a request with conditional headers ( If-Modified-Since / If-None-Match). The server compares these with Last-Modified or ETag values to decide whether to return a 304 Not Modified response (cache hit) or the full resource.

Cache strategies

Last-Modified / If-Modified-Since : uses the resource's last modification timestamp.

ETag / If-None-Match : uses a unique identifier generated by the server; more precise than timestamps.

When both are present, the server validates the ETag first, then the Last-Modified value.

Local Cache

Local caching mechanisms differ across browsers. Common options include cookies, localStorage, sessionStorage, and IndexedDB.

Cookie

Supported by all browsers.

Size limit ~4 KB per origin.

Has an expiration time.

Can be cleared by antivirus or browser cleaning tools.

Not stored in private/incognito mode.

Requires a round‑trip to the server for each request.

localStorage

Not compatible with IE 8 and below.

Size limit ~5 MB per origin.

Persistent until explicitly cleared via the API.

Usually not removed by cleaning tools (new Chrome may purge).

Available in private mode.

Does not involve the server.

sessionStorage

Same API as localStorage but scoped to the current tab session; cleared when the tab is closed.

Both localStorage and sessionStorage are unsuitable for large data sets; IndexedDB is recommended for sizable client‑side databases.

IndexedDB

Key‑value store supporting any JavaScript object.

Asynchronous API, preventing UI blocking.

Supports transactions; a failure rolls back the whole transaction.

Same‑origin restriction.

Large storage capacity (typically >250 MB, often unlimited).

Can store binary data (ArrayBuffer, Blob).

Cache Refresh Strategies

Force refresh bypasses If-Modified-Since and forces the browser to retrieve resources from disk cache or memory cache.

From memory cache : resource is served from RAM without a network request; cleared when the page is closed.

From disk cache : resource is read from the hard drive; persists across page reloads.

Browser Cache Principles

Home pages (frameworks) should disable caching to ensure the latest resources.

For APIs that report data frequently, disable caching or use versioning/random query strings.

Only cache 200 responses; redirects (3xx) are typically not cached.

Static assets like JS/CSS can be cached long‑term with versioned URLs.

Non‑strongly consistent data may be cached for a few seconds.

Use ETag for validating asynchronous API responses.

Add a Server header on the backend to aid troubleshooting.

Application Cache Strategies

For mobile apps and clients that may operate offline, consider the following patterns:

Polished loading experience.

Pre‑push data to avoid traffic spikes during flash‑sale events.

Fallback data displayed when the server is down or the network is unavailable.

Temporary cache cleared on exit.

Fixed cache for rarely changing framework resources.

Parent‑child linking to reuse content across page navigation.

Pre‑loading resources based on predicted user actions.

Asynchronous loading of content after the shell is rendered.

Source: https://www.cnblogs.com/Courage129/p/14419192.html