Re: [w3c/ServiceWorker] Eliminating SW startup latency for common case (#920)

Right, let's sort out the API for this. How about:

```js
self.addEventListener('install', event => {
  event.addNavigationPreload();
});

self.addEventListener('fetch', event => {
  event.respondWith(event.preloadResponse || fetch(event.request));
});
```

* `addNavigationPreload` must be called while the service worker's state is `installing`.
* This setting sits with the service worker, not the registration, so if the next version of the service worker does not call `addNavigationPreload`, there will be no preloads once that service worker is active.
* The preload happens for fetches with mode "navigation" only, and happens for *all* in-scope fetches with mode "navigation".
* The preload request is the same as the original, except for the addition of a `Service-Worker: navigation-preload` header.
* `preloadResponse` is a promise for a response, or null if no preload was made.
* If `preloadResponse`'s is unresolved by the time the fetch event has ended (including `waitUntil` etc), the browser may abort the request.
* If `preloadResponse` response body has not been used by the time the fetch event has ended (including `waitUntil` etc), the browser may abort the response.

How's that?

@n8schloss you mentioned wanting to set a header to a particular value, but the more I think about it the more it feels like cookies with a different name. If we had a cookie API in service worker, would that be enough here?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/920#issuecomment-245621515