Reference

Cache API glossary

Shared vocabulary for this workspace. Lessons stick to these meanings.

Lesson 1 Lesson 2 Lesson 3 Lesson 4 Lesson 5 Open / put / match Strategies Checklist Playbook Resources Mission

Cache Storage API (Cache API): Browser API for storing and retrieving Request / Response pairs in named caches. Code-driven (your script decides what enters and leaves). Available from windows, workers, and service workers — not limited to service workers only.
CacheStorage (caches): The master directory of named caches for an origin, exposed as the global caches object. Methods include open, keys, delete, has, and match (search across caches).
Named cache: One Cache object opened with a string name (e.g. static-v3). An origin may have many named caches; naming is how you version and delete whole generations of assets.
Request / Response pair: The only shape Cache Storage stores: an HTTP-shaped Request key and a Response value (body + headers/status). Any data that can travel over HTTP can sit in the body — but the model is still “this is a network resource,” not “this is a row in my app database.”
HTTP cache: The browser’s built-in cache driven by headers (Cache-Control, validators, heuristics). Separate from Cache Storage. Service-worker / Cache API caching is code-driven; the two layers interact and can fight if you ignore each other.
Service worker: A special worker that can intercept fetch events for an origin’s controlled pages. The most common place Cache Storage is used for offline shells and runtime strategies — but the Cache API itself also works from the page and other workers.
Origin-scoped: Storage is isolated to a site origin (scheme + host + port). Other origins cannot read your Cache Storage data.
Client storage: Data kept in the browser (or device) for an origin — not the same as “source of truth on the server.” Includes memory, Web Storage, Cache API, OPFS, IndexedDB, cookies, etc.
IndexedDB: Async structured client database (object stores, keys, indexes). Prefer for app entities, drafts, and offline queues — not as the default home for HTML/JS/CSS shells (that’s Cache Storage).
Web Storage: localStorage / sessionStorage: synchronous string maps with small practical limits. Wrong tool for bulk assets or Request/Response caching.
Origin Private File System (OPFS): Origin-scoped file-system-like storage for file-shaped content. Prefer when the data model is files/bytes more than HTTP resources or keyed records.
Opaque response: A cross-origin response you cannot inspect (status often appears as 0), typically from a no-CORS fetch. add / addAll will not store them; put can — with real caveats for size accounting and debugging. Treat carefully.
Quota: How much an origin may store. Shared across Cache Storage and IndexedDB (among others). Writes can fail with QuotaExceededError; browsers may also evict best-effort data under pressure.
Eviction: Browser removal of origin data under storage pressure or policy (e.g. Safari’s time-based rules for some script-writable storage). Default storage is best-effort unless persistent storage is granted.
Caching strategy: A policy for how a service worker answers a fetch: e.g. cache-first, network-first, stale-while-revalidate, network-only, cache-only. Cache Storage is the store; the strategy is the decision logic around it.