[w3c/ServiceWorker] Service Worker handling of first page load subresources (#1282)

This was throughly discussed before (at https://github.com/w3c/ServiceWorker/issues/73 and https://github.com/w3c/ServiceWorker/issues/938 at the very least), but I believe there's merit to raising the issue again.

Service Workers have many use-cases nowadays. Offline browsing is one of them, but others would significantly benefit from being able to manage requests and responses of subresources in the very first page load on which the Service Worker is installed.

## Use cases
### Lazy loading of resources
Web content today contains many resources which may or may not be needed to render the very first view. This includes images and javascript resources. There are many JS based solutions to lazy load certain resources, but it’s hard to make them bullet proof in the face of HTML based resources as well as JS based ones both from first and third party code.

Service Workers provide an elegant way to defer the loading of resources until a later point in time.
### Third party SPOF prevention
Many developers integrate third party services to their sites. That means that when those third parties have a Bad Day™, the sites in question run a risk of having their first render, DCL or load event delayed until the OS gives up on said third party and initiates a reset of the connection.

Service Workers provide a handy technique for dealing with that, and terminate those third party requests if they are taking too long.

### Decompression
Service Workers also potentially enable the use of new and exciting compression schemes by allowing developers to perform proprietary decompression of those schemes in Service Workers.

While that’s possible, the first load of the page (which arguably requires the most help on the performance front), won’t be able to benefit from such optimizations.

## Potential solution
The above use-cases all require that the SW will be installed before any subresource requests are being sent out for the document, but not necessarily before the document itself - the document request and response do not have to be processed by the Service Worker.

### SW code push + early hints installation
The solution outlined here involves two different mechanisms: Server Push in order to deliver the SW resource to the browser and [Early Hints](https://tools.ietf.org/html/rfc8297) + `<link rel=serviceworker>` in order to trigger the renderer to install that Service Worker ASAP.

The combination of these two technologies would enable servers to send down both the instructions to install the ServiceWorker as well as its resource to the browser, while the HTML contents are being calculated on the server. Once the browser received the 103 response with the SW installation instructions, it will start fetching the service worker, and will hopefully find its contents already in its network stack. Then it can start speculatively installing the service worker (even though the document may not be committed just yet), and hopefully finish the installation before the HTML processing starts and subresources are discovered.

In case where the race is lost and HTML is processed before the SW has finished installation, the requests will go out without triggering the SW's `fetch` event. Developers can use an fast-installing, "bootstrapping" SW in these cases to minimize the race. 

Thoughts?


-- 
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/1282