Definition

Precaching

Short definition

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.

Reviewed July 31, 2026

A basic manual example: event.waitUntil(caches.open("shell-v3").then((cache) => cache.addAll(["/", "/styles.css", "/main.js"])));. If any single URL in the list 404s, the entire addAll() call rejects and the install fails, which is a deliberate safety mechanism so a broken precache list never gets partially committed.

Precache lists are almost always generated at build time rather than hand-written, since they need to include hashed filenames like /main.a1b2c3.js that change on every deploy — Workbox's workbox-build and workbox-webpack-plugin generate this list automatically from your build output.

Precaching trades a slightly longer or more bandwidth-heavy install step for guaranteed offline availability of the app shell; it is distinct from runtime caching, which only stores a response after the user actually triggers the matching request.

Because precached entries are keyed to a specific build's cache name (e.g. "shell-v3"), each deploy should use a new cache name and clean up the old one in the activate event to avoid unbounded storage growth.

Related terms

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.

Cache Storage API

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.

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.

Push API

The Push API lets a service worker subscribe to a browser-run push service and receive encrypted messages from a server at any time, including when no tab or window for the site is open. Subscribing is done with registration.pushManager.subscribe({ userVisibleOnly: true, applicationServerKey }), and incoming messages arrive in the worker's push event.

VAPID

VAPID (Voluntary Application Server Identification) is a key-pair scheme, standardised in RFC 8292, where a server generates one ECDSA P-256 key pair, keeps the private key secret, and shares the public key with browsers via the applicationServerKey option when subscribing. It lets push services verify which application server is sending a given message without requiring a proprietary developer account per browser vendor.

PushSubscription

A PushSubscription is the object returned by pushManager.subscribe(), containing an endpoint (a unique, vendor-hosted URL that identifies this specific device/browser installation) and a keys object with p256dh and auth values used to encrypt messages sent to it. Your server stores this per user and sends future notifications by POSTing an encrypted payload to subscription.endpoint.