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

`RequestStorage` API isn't really supposed to be related to the case in this issue. I originally came with its idea in https://github.com/w3c/ServiceWorker/issues/959 issue. The reason why is to have a way to reuse existing requests. I'm not particularly sure how often this would happen in the wild, but the use case was:

* Go to page `A`
* Preload page `B` with <link>/Link header
* Preload page `B`'s assets by Link header in `B`'s response
* If user clicks on the `B` link on the `A` page -- **reuse existing preload requests**, or load from cache, or load from network

This is why I got the idea about `self.requests.match()`. Next I thought that the problem in this issue could be also solved with such API. Ideally, I think that all requests which possibly may/need to bypass SW (for performance reasons) are ended up in `self.requests` storage. In the example on my proposal I showed that only `preflight` requests goes automatically (browser puts it) into `self.requests`, but ideally all `Link` header preloads of that `preflight` request should be put into `self.requests` by the browser. The reason of course, as you mentioned, is that `preflight` might be finished before SW starts up, so browser will be able to start preloading of other critical data before SW handles preflight request.

One real world example might be this, which I had in one of my previous projects: We had very fast _newsfeed_ generation, but very slow generation/fetching of likes for the newsfeed. So we ended up with 2 requests: one for newsfeed on one for likes, to show content to the user as fast as possible.

In the case with `preflight` + `preload` with Link header that could be optimized while still serving app shell from SW.

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