Browser Web Caching Mechanisms and Strategies

Introduction

Browser caching strategies are familiar to front‑end developers, but a systematic summary helps avoid misunderstandings, especially in interviews.

Web Cache Overview

Web cache refers to a copy of a web resource (HTML, images, JavaScript, data, etc.) stored between the web server and the client (browser). The cache saves the response of a request; when a subsequent request for the same URL arrives, the cache decides whether to serve the stored copy or forward the request to the origin server.

Benefits of Web Caching

Reduces network latency and speeds up page load.

Decreases bandwidth consumption.

Lowers server load.

HTTP Caching Mechanism

Simplified Process

Rules for Caching

Freshness (expiration): a cached copy is considered fresh if it has a valid expiration header and is still within its lifetime, or the browser has already validated it during the session.

Validator (validation): the server may send an ETag header; the browser uses it to verify whether the cached resource is still valid.

Two Stages of HTTP Caching

Browser caching is divided into strong cache (also called local cache) and negotiated cache (also called weak cache).

Strong Cache Stage

Before sending a request, the browser checks the strong cache. If a hit occurs, the resource is read directly from the cache without contacting the server.

Negotiated Cache Stage

If the strong cache misses, the browser sends a request. The server examines request‑header fields to decide whether the resource can be served from the negotiated cache. A 304 response indicates a cache hit; otherwise the resource is fetched from the server.

Enabling/Disabling Cache

Developers can use HTML meta tags to control caching, e.g.:

<meta http-equiv="Cache-Control" content="no-store" />

Note: only IE fully respects this meta tag; other browsers rely on the “Cache‑Control: no-store” header.

Relevant HTTP Headers

Common cache‑related headers include:

Cache‑Control (max‑age, no‑cache, no‑store, public, private, etc.)

Expires (absolute expiration time)

Last‑Modified and If‑Modified‑Since

ETag and If‑None‑Match

Cache‑Control takes precedence over Expires. Browsers may still cache resources even without explicit caching headers, based on their own default heuristics.

Cache Locations

Browsers store cached copies in memory or on disk. The lookup order is Service Worker → Memory Cache → Disk Cache → Push Cache.

Memory Cache

Fast access, cleared when the process ends, suitable for small or short‑lived resources.

Disk Cache

Slower than memory but persists across sessions, suitable for larger files.

Prefetch/Preload Cache

Resources loaded via preload or prefetch are stored in the HTTP cache; if cacheable they remain there for later use.

CDN Cache

Example headers from Tencent CDN:

X-Cache-Lookup: Hit From MemCache – cache hit in CDN memory.

X-Cache-Lookup: Hit From Disk – cache hit on CDN disk.

X-Cache-Lookup: Hit From Upstream – cache miss, request forwarded to origin.

Overall Flow

Typical refresh scenarios:

F5 – bypasses strong cache but checks negotiated cache.

Ctrl+F5 – forces a full reload, bypassing both caches.

Other Web Caching Strategies

IndexedDB

IndexedDB provides a client‑side database for storing large structured data with indexing capabilities. It uses asynchronous APIs such as indexedDB.open() which returns an IDBRequest object.

Service Worker

Since 2014, Service Workers enable offline caching, push notifications, and fine‑grained control over network requests via the Cache and CacheStorage APIs.

LocalStorage & SessionStorage

LocalStorage persists data across sessions until explicitly cleared; SessionStorage persists only for the duration of a page session.

Defining an Optimal Cache Strategy

Use consistent URLs; avoid case‑sensitive duplicates.

Identify which resources are suitable for CDN or intermediate caches.

Determine appropriate max-age for each resource.

Combine short‑lived HTML with longer‑lived static assets.

Separate frequently changing code into its own files to minimize download size.

Configure or remove ETag as needed per server.

Leverage HTML5 storage mechanisms (LocalStorage, SessionStorage, IndexedDB, Service Workers) for performance gains.

Utilize native storage capabilities to tailor caching for the best user experience.

Conclusion

Understanding browser caching mechanisms and storage options enables developers to craft effective cache policies, improve performance, and regularly audit applications for missed caching opportunities.

References

https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9

https://www.digitalocean.com/community/tutorials/web-caching-basics-terminology-http-headers-and-caching-strategies

https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=en

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Caching_FAQ

https://developer.mozilla.org/zh-CN/docs/Web/API/IndexedDB_API

https://juejin.im/post/5a673af06fb9a01c927ed880

https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=zh-cn