A service worker handles navigation requests network-first and falls back to a cached /offline.html. On a cold visit the page feels slower than it did before the worker existed. What causes that delay, and what does navigation preload do about it?

## Where the extra time comes from A service worker is not a resident process. The browser terminates it when it goes idle and starts it again when an event needs it, which is the whole reason worker code has to be stateless between events. That policy is invisible for subresource requests, because by the time the page is fetching scripts and images the worker is already running. It is very visible for the **navigation** request, which is the event that wakes the worker up. On a cold navigation the sequence is: browser decides the URL is in a controlled scope → reads and evaluates the worker script → runs its top-level code and registers handlers → dispatches `fetch` → your handler finally calls `fetch(event.request)`. Everything before the last step is dead time added in front of the document, and the document is on the critical path for absolutely everything else. A network-first navigation handler therefore *costs* something even when the network is fast, which surprises teams who added the worker purely to make things faster. ## What navigation preload changes Navigation preload lets the browser start the network request for the navigation at the same moment it starts booting the worker. By the time your handler runs, the request is already in flight — often already finished — and it is handed to you as a promise: ```js self.addEventListener('activate', (event) => { if (self.registration.navigationPreload) { event.waitUntil(self.registration.navigationPreload.enable()); } }); self.addEventListener('fetch', (event) => { if (event.request.mode !== 'navigate') return; event.respondWith((async () => { try { const preloaded = await event.preloadResponse; if (preloaded) return preloaded; return await fetch(event.request); } catch { return (await caches.match('/offline.html')) || Response.error(); } })()); }); ``` Three rules govern that code. `event.preloadResponse` is a promise that resolves to `undefined` when preload is off or the request was not a navigation, so the `if (preloaded)` branch is mandatory rather than defensive. You must consume it — if you enable preload and then ignore the promise, the browser has issued a request nobody reads, which is wasted bandwidth and, for a non-idempotent endpoint, a wasted server hit. And the enable call belongs where it runs once per worker generation rather than on every fetch. ## The server-side half Preload requests carry the header `Service-Worker-Navigation-Preload`, whose value defaults to `true` and can be set with `navigationPreload.setHeaderValue(value)`. Origins use it to serve something cheaper for a preload — commonly a shell or a partial the worker is expected to compose — though most deployments simply ignore the header and return the normal document. ## The offline fallback in this design The fallback path is the other half of the recipe. Precache `/offline.html` so it is guaranteed present, and return it from the `catch` when both the preload and the direct fetch reject. Note the shape of the error handling: a rejected `fetch` means the network failed, but an HTTP error status resolves normally, so a 500 will be passed straight through to the user unless you also check `response.ok` and decide whether an error page is friendlier than the origin's. ## When to reach for it Navigation preload only pays when the worker is genuinely cold and the navigation is network-bound — that is, network-first or stale-revalidating documents. If your document is served cache-first from a precached shell you were never waiting on the network to begin with. Feature-detect before enabling, because the API landed in different engines years apart.