Cache Storage API

The Cache Storage API lets web applications maintain named caches containing `Request`/`Response` pairs. It is especially useful with service workers for intercepting fetches and serving previously stored responses, enabling offline behavior and controlled caching.

Cache Storage is exposed through the `caches` global and provides named `Cache` objects. A service worker can open a cache with `caches.open("app-v1")`, then add or retrieve resources from it.

A `Cache` stores HTTP-style request-response pairs. Common methods include `cache.put(request, response)`, `cache.add(request)`, `cache.match(request)`, and `cache.delete(request)`. `caches.match(request)` can search across the available named caches.

Service workers commonly use Cache Storage during their `install` event to pre-cache application assets. During `fetch`, the worker can check the cache first and fall back to the network when no suitable cached response exists.

Cache Storage is distinct from the browser's normal HTTP cache. Application code can explicitly control Cache Storage entries, while the HTTP cache is primarily managed by the browser according to HTTP caching rules and response metadata.

Key points

• `caches.open(name)` creates or opens a named cache.
• Caches store `Request`/`Response` pairs rather than arbitrary JavaScript values.
• `cache.match()` retrieves a matching cached response; `cache.put()` stores an explicit pair.
• Service workers commonly use Cache Storage for offline and network interception strategies.
• Cache Storage is separate from the browser-managed HTTP cache.

Interview questions

What is the Cache Storage API used for?

It provides named caches for storing and retrieving `Request`/`Response` pairs. Service workers can use it to cache resources such as HTML, CSS, JavaScript, and images. This makes it possible to serve resources without contacting the network every time. A common use case is supporting offline or partially offline experiences.

How do you open and use a named cache?

Call `caches.open()` with a cache name. It returns a promise that resolves to a `Cache` object. You can then call methods such as `put()`, `add()`, `match()`, and `delete()` on that object. Opening an existing name accesses that cache rather than requiring a new object each time.

How would you implement a cache-first service-worker strategy?

In the service worker's `fetch` handler, first query Cache Storage for a matching response. If a match exists, return it immediately; otherwise, request the resource from the network. Depending on the application's needs, the network response can then be stored for subsequent requests. The strategy improves offline resilience but can serve stale content unless cache updates are deliberately handled.

How should a service worker manage old cache versions?

A service worker can use versioned cache names, such as `app-v2`. During activation, it can enumerate existing cache names with `caches.keys()` and delete caches that are no longer needed. This prevents obsolete assets from accumulating and allows a new service-worker version to establish a clean cache set. The deletion policy should preserve any caches still required by the application.

What is an important difference between Cache Storage and the HTTP cache?

Cache Storage is an application-visible API that lets code explicitly create named caches and manipulate stored request-response pairs. The HTTP cache is a browser-managed caching mechanism governed largely by HTTP caching semantics such as cache headers. A service worker can use both mechanisms, but putting a response into Cache Storage does not mean the same thing as relying on normal HTTP caching. This distinction matters when designing freshness, invalidation, and offline behavior.