Re: [w3c/ServiceWorker] Making a concurrent request for navigations (#920)

Here's a proposal for a registration-based API:

```js
// enabling the feature.
self.addEventListener('activate', event => {
  event.waitUntil(
    self.registration.navigationPreload.enable()
  );
});
```

`navigationPreload.enable` can be called at any point, but the recommendation will be to call it in the activate event. That way it'll be enabled when there's a service worker in place that has a fetch event listener that knows what to do with it.

The preload will have the header `Service-Worker-Navigation-Preload: true`. We suggested `Navigation-Preload` at the F2F, but my feeling is this could get confused with `link[rel=prerender]`.

```js
// disabling the feature.
self.addEventListener('activate', event => {
  event.waitUntil(
    self.registration.navigationPreload.disable()
  );
});
```

Both `enable` and `disable` return a promise that resolves once the setting is updated on the registration.

```js
// access to response (same as previous proposals)
self.addEventListener('fetch', event => {
  event.respondWith(event.navigationPreload || fetch(event.request));
});

// setting the header
self.registration.navigationPreload.setHeaderValue("hello");
```

The header can be set at any point. Setting returns a promise that resolves once the registration is updated. Setting the header does not auto-enable the feature. This means page code can be updating the header without enabling the feature for a service worker that isn't ready for it.

Also:

```js
self.registration.navigationPreload.getState(state => {
  console.log(state); // {enabled: false, headerValue: "true"}
});
```

Any takers?

-- 
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-251150270