Definition

Network-first strategy

Short definition

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.

Reviewed July 30, 2026

Because it waits for the network by default, network-first can feel slower than cache-first on poor connections — a common refinement adds a timeout (e.g. race the fetch against a 3-second timer) so the app falls back to cache sooner on very slow networks rather than only on outright failure.

Every successful network response should be cloned before both being returned to the page and stored in the cache, since a Response body can only be read once — forgetting response.clone() is one of the most common service worker bugs.

Network-first is a poor fit for large, rarely changing assets because it forces a network round trip even when the content is guaranteed unchanged; those cases are better served by cache-first or stale-while-revalidate.

Workbox implements this as workbox.strategies.NetworkFirst, with a configurable networkTimeoutSeconds option that automates the timeout-then-cache pattern described above.

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.

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.

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.

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.

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.