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

I'll try (although I though I had by clarifying the requirements):

 - First, the route based proposal doesn't appear to allow the server to decide how to overload the first response to serve only data (not UI + data).
 - Next, blocking on the SW is usually OK because now we're in a race. SW startup can be in the 10s to hundreds of ms in the worst cases, but isn't usually worse than that. You burn as much on DNS. As a result, it won't generally be a net loss to wait on the SW for mediating this interaction, particularly if you can shave off overhead of getting a new request out the door.
 - 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).

I think we should probably do declarative routing. We should probably go with something not dissimilar from your proposal, @jakearchibald, but I don't think it solves the issues @n8schloss or @bmaurer are raising nor does it really help our PlzNavigate integration. It's also quite a bit larger.

As a final thought, I think these can layer together quite nicely. 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.

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