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

@slightlyoff 

>  the route based proposal doesn't appear to allow the server to decide how to overload the first response

These could easily be options to `FetchSource`.

```js
event.declareRoute({mode: 'navigation'}, new FetchSource({
  applyHeaders: {
    'X-Site-Specific-Header': "thinger"
  }
}), {fireFetchEvent: 'yes'});
```

I think that's equivalent to your proposal (I don't know for sure as you haven't described how your proposal works),

> blocking on the SW is usually OK because now we're in a race

Are we sure that's the case? Based on [the code example above](https://gist.github.com/jakearchibald/4927b34bb14c3681a3c1c1ce6ede5b09), if we had routing, the following could happen while the SW was booting up:

* Shell fetched from cache, giving a first render
* JS fetched from cache
* JS parsed & executed
* Fetch called for data

If that takes longer than 200ms, then we've won. Not only that, but we rendered while that was happening.

Contrast this to your preflight proposal, where:

* Render is blocked by SW startup, and potentially the network request too (you haven't explained how it works)
* The fetch call is a separate request, so it won't have the preflight there, so I don't see how the problem is solved
* The fetch call may also be blocked on the network, even if it doesn't need to be.

> Lastly, the routing based proposal either has to defeat PlzNavigate entirely (if you only specify a FetchSource()) or, as I understand the example given, still wait on the renderer process for handling the CacheSource() entries (it's unclear we'd want the mapping logic for them in the browser process).

If you're racing `FetchSource` with other sources it won't be a problem. That's basically what your proposal is doing (I think), but it only does that.

> Having the preflight come back as a readable stream that can be directed to the document (in cases where you might use a FetchSource() or a CacheSource()) doesn't seem to be at odds with the declarative proposal. It does mean you'd need to wake the SW to handle it, but that could also be turned into a declarative option I suppose.

We're already talking about hacking around your proposal. It's too high level, and too all-encompasing. Also, you *still* haven't answered my questions on how it works.

My questions are in https://github.com/slightlyoff/ServiceWorker/issues/920#issuecomment-229015463. The outstanding questions are:

* Is the preflight opt-in? If so, by what mechanism?
* Does the preflight happen for every request, or just navigations?
* What type is `e.preflightResponse` is it a `Response`?
* What happens if the fetch event can fire before `e.preflightResponse` is ready? 
* If I do not use the preflight, what happens to it? Eg what if it's a 3gb video?
* If my SW does fetch(event.request), is that an additional request? That will be the case for most existing SWs
* If my SW does fetch(event.request.url), is that an additional request?

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