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

A few things seems missing from the conversation.

Many sites we've partnered with have deployed nearly-no-op SWs to do tracking and monitoring. This defeats the no-`onfetch` optimisation. Sites like FB and Google Inbox have goals that they go to extraordinary lengths to meet but have difficulty achieving thanks to the complexity of their stacks and the # of folks adding features:

1. Get UI to users as fast as possible
2. Get fresh data into that UI, even though the UI is script-mediated (and, if not possible, show stale data)
3. Monitor the performance of the overall experience end-to-end

Getting UI to users tends to involve "booting up" large amounts of JS, CSS, and associated context. This is true for FB, Inbox (in some modes), Docs (in some cases), and many others. In a no-SW world, the best strategy is to inline fresh content into the response document where the booted code can consume it and render it.

With SWs in the mix or server-rendering of snapshots (Inbox & Docs, but only in certain modes), things get more complicated. A service designer of one of these systems wants to be able to:

 - Get UI to the user reliably; that is to say, if there's a "header" or "shell" that can be served from cache with low variance, that's a good thing to do, even if the total latency may be slightly higher due to SW wakeup costs
 - Get requests for fresh data onto the network ASAP. Assuming you respond with a "shell" for `example.com/` (which we might imagine coming from a declaratively routed cache as @jakearchibald  suggests, but not necessarily so), it'd be helpful to get a request to the server for new data started as soon in the lifetime as possible.
 - Ensure that everything works sensibly when there's no SW in play

To handle the second of those, the proposal I've provided lets the server know a few things:

1. A Service Worker is in play and therefore the app shell or "header" resources are already booting up
2. That, as a result, it's safe to respond with _just_ data, not any cruft or dressing associated with a full-page render. In sever-language, it allows the server to send only a "partial"
3. That the response won't be dropped on the floor because the SW will be in play to handle (and redirect) it

It does this with minimal new infrastructure, enabling both streaming for "static" sites that want to handle HTML partials and not data, as well as allowing sites that deal in data (vs. inline HTML) to do so naturally.

Would love to hear from @bmaurer on the alternatives proposed here as well.

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