Cache class

The interface provides a persistent storage mechanism for [Request] / [Response] object pairs that are cached in long lived memory. How long a Cache lives is browser dependent, but a single origin's scripts can typically rely on the presence of a previously populated Cache. Note that the interface is exposed to windowed scopes as well as workers. You don't have to use it in conjunction with service workers, even though it is defined in the service worker spec. An origin can have multiple, named objects. You are responsible for implementing how your script (e.g. in a ServiceWorker) handles updates. Items in a do not get updated unless explicitly requested; they don’t expire unless deleted. Use CacheStorage.open() to open a specific named object and then call any of the methods to maintain the . You are also responsible for periodically purging cache entries. Each browser has a hard limit on the amount of cache storage that a given origin can use. Cache quota usage estimates are available via the StorageManager.estimate() method. The browser does its best to manage disk space, but it may delete the Cache storage for an origin. The browser will generally delete all of the data for an origin or none of the data for an origin. Make sure to version caches by name and use the caches only from the version of the script that they can safely operate on. See Deleting old caches for more information.

Note: The key matching algorithm depends on the VARY header in the value. So matching a new key requires looking at both key and value for entries in the Cache. Note: The caching API doesn't honor HTTP caching headers.

Note: This feature is available in Web Workers

Secure context: This feature is available only in secure contexts (HTTPS), in some or all supporting browsers.

Constructors

Properties

Methods

Operators

service_workers library