Definition

Cache Storage API

Short definition

The Cache Storage API, exposed as the global caches object, lets a service worker (or page) store Request/Response pairs in named caches, e.g. caches.open("shell-v1").then((cache) => cache.put("/logo.png", response)). Unlike the HTTP cache, it is fully scriptable, has no automatic eviction schedule tied to headers, and persists until explicitly deleted or the storage quota is exceeded.

Reviewed July 29, 2026

Reading back a cached response is as simple as caches.match(request), which searches every open cache by default unless a specific cache name is passed, matching by request URL and method.

Storage is per-origin and shares the same quota as IndexedDB and localStorage; browsers use a "least recently used" eviction policy across all of an origin's storage once the device is low on space, which is why caches should be versioned and pruned rather than left to grow unbounded.

Cache Storage entries are opaque to the network layer — putting a response in cache does not affect how the browser's HTTP cache behaves, and the two systems operate independently even though a fetch() call can populate both.

The full API surface (Cache, CacheStorage interfaces) is documented at https://developer.mozilla.org/en-US/docs/Web/API/Cache.

Related terms

Cache-first strategy

Cache-first is a fetch-handling strategy: event.respondWith(caches.match(event.request).then((cached) => cached ?? fetch(event.request))). It serves cached content instantly and skips the network entirely when a match exists, making it ideal for versioned, immutable assets such as hashed JS/CSS bundles or app-shell icons that never change once deployed.

Precaching

Precaching means fetching and storing a known list of build-time assets (HTML shell, CSS, JS bundles, key icons) in Cache Storage inside the install event handler, so they are guaranteed to be available offline from the very first load rather than being cached only after a user happens to request them.

Runtime caching

Runtime caching means storing a response in Cache Storage the first time a matching request is actually made by the user, inside the fetch event handler, as opposed to precaching, which loads a known asset list upfront during install. It is the natural fit for content whose full URL set is not known ahead of time, such as user-generated images or paginated API results.

Network-first strategy

Network-first is a fetch-handling strategy: event.respondWith(fetch(event.request).then((res) => { cache.put(event.request, res.clone()); return res; }).catch(() => caches.match(event.request))). It prioritises up-to-date data and only serves a cached copy if the network request fails outright, making it the standard choice for API calls and frequently changing pages.

Stale-while-revalidate

Stale-while-revalidate is a fetch-handling strategy that serves whatever is already in Cache Storage without waiting on the network, then kicks off a background fetch to refresh that cache entry for the next request. It gives cache-first speed with eventual freshness, at the cost of occasionally showing content that is one request-cycle out of date.

Workbox

Workbox is a collection of JavaScript libraries and build tools (workbox-precaching, workbox-routing, workbox-strategies, workbox-expiration, and more) maintained by the Chrome team that implement the recurring service worker patterns — precache manifests, route matching, cache-first/network-first/stale-while-revalidate strategies — so teams do not hand-roll them from scratch.