Mastering Client-Side Caching: HTTP, Cookies, LocalStorage & IndexedDB Explained

Client‑side caching consists of HTTP caching and local caching; using cache offers many benefits such as reducing duplicate data transmission, saving network bandwidth, alleviating bottlenecks, lowering server load, preventing overload, and allowing the server to respond faster to other requests.

HTTP Cache

HTTP cache is divided into strong cache and negotiated cache , mainly used to store static files that rarely change, such as images, CSS, JS. Before describing strong and negotiated cache, understand the HTTP cache process:

Strong Cache

When the browser requests a resource, it first obtains the resource's header information and checks whether it hits a strong cache (via Cache‑Control or Expires). If it hits, the resource is retrieved directly from the cache, including headers, and no communication with the server occurs.

Cache Scheme

Expires : the expiration time in the response header; if the resource is requested again within this period, the strong cache is hit.

Cache‑Control : when set to max-age=300, the resource will be served from the strong cache for 5 minutes after a successful response.

Cache‑Control and Expires serve the same purpose of indicating the resource’s validity period, but Cache‑Control offers finer‑grained control and takes precedence when both are present.

Common Cache‑Control directives include public, private, no‑cache, no‑store, no‑transform, must‑revalidate, proxy‑revalidate, max‑age, etc. Their meanings are:

public : response may be cached by any cache.

private : response is intended for a single user and must not be stored by shared caches.

no‑cache : request or response must not be cached.

no‑store : neither request nor response is stored in any cache.

max‑age : client may use the response for the specified number of seconds.

min‑fresh : client may accept a response whose age is less than the specified value.

max‑stale : client may accept a stale response up to the specified number of seconds.

Negotiated Cache

If strong cache is missed, the browser sends a request containing the original cache‑related headers (Last‑Modified/If‑Modified‑Since and ETag/If‑None‑Match). The server compares these values to determine whether the resource can be served from the cache. If it matches, the server returns updated headers without the resource body; otherwise it returns the fresh content.

Cache Scheme

Last‑Modified / If‑Modified‑Since : the server includes a Last‑Modified timestamp in the initial response; subsequent requests include If‑Modified‑Since, and the server uses it to decide whether the cached copy is still valid.

ETag / If‑None‑Match : the server provides a unique identifier (ETag) for the resource; subsequent requests include If‑None‑Match with that ETag, and the server compares it to determine cache validity.

Differences between Last‑Modified and ETag

Files that change frequently but keep the same content may update the modification time without actual changes; ETag can avoid unnecessary re‑fetches.

High‑frequency updates (sub‑second) cannot be captured by the second‑level granularity of If‑Modified‑Since.

Some servers cannot provide an accurate modification time; ETag offers a precise identifier generated by the server.

When both are present, the server validates the ETag first; if it matches, the Last‑Modified check follows before deciding whether to return a 304 response.

Local Cache

Local cache is closely related to the browser and varies across browsers. Common local caching mechanisms include:

Cookie

Compatible with all browsers.

Size limit of about 4 KB per origin.

Has an expiration time (can be set manually).

May be cleared by antivirus software or browser cleaning tools.

Not recorded in private or incognito mode.

Not strictly local storage because it is sent to the server with each request.

Chrome’s cookie cache

localStorage

Not compatible with IE 8 and below.

Size limit of about 5 MB per origin.

Persistent storage; data remains until manually removed.

Usually not cleared by antivirus or cleaning tools (new Chrome versions may clear it).

Recorded in private/incognito mode.

No interaction with the server.

sessionStorage

Similar API to localStorage but data is cleared when the tab or window is closed.

Both localStorage and sessionStorage provide roughly 5 MB of space and are unsuitable for large data sets; for larger caches, a client‑side database such as IndexedDB should be used.

IndexedDB

IndexedDB offers the following features:

Key‑value storage; any type of data, including JavaScript objects, can be stored.

Asynchronous API that does not block the UI.

Support for transactions; a failure in any step aborts the entire transaction.

Same‑origin restriction; each database is scoped to its creating domain.

Large storage capacity, typically at least 250 MB and often unlimited.

Ability to store binary data (ArrayBuffer and Blob).

Cache Forced Refresh

During a forced refresh the browser omits the IF-Modified-Since header and instead sends from disk cache & from memory cache to verify whether the request used the browser cache and whether a request was sent to the server.

When clicking links, loading external resources, or navigating forward/backward, the following cache sources may be used:

from memory cache : the resource is retrieved directly from memory without contacting the server; it is released when the page is closed.

from disk cache : the resource is read from the disk cache without contacting the server; it persists across page reloads.

Age : a CDN‑added header indicating how many seconds the response has been cached in the CDN.

via : identifies the chain of servers the CDN request passed through and whether the cache was hit.

Browser Cache Principles

The homepage should disable caching to ensure the latest resources are loaded.

Some scenarios, such as polling APIs, also require cache disabling.

Complete disabling of browser cache is difficult; version numbers or random query strings are commonly used.

Only cache 200 responses; redirects (3xx) should not be cached.

Static assets like JS and CSS can be cached for a long time and updated via versioning.

Data that does not require strong consistency can be cached for a few seconds.

Asynchronous API data can be validated with ETag.

Adding a Server header on the backend aids troubleshooting.

Application Cache Strategies

Beautiful loading experience.

Pre‑fetch data to avoid traffic spikes during flash sales.

Fallback data : display when the server crashes or the network is unavailable.

Temporary cache : cleared on exit.

Fixed cache : for rarely changing framework components, delivered with the client.

Parent‑child linking : reuse parts of a page when navigating without reloading.

Pre‑loading : asynchronously load resources based on predicted user actions.

Asynchronous loading : show the framework first, then load content asynchronously to avoid blocking the main thread.

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