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

Declarative routing is definitely more broadly useful.

>From an implementation perspective, if we're talking about minimizing latency so that a site can know ASAP when a session is starting for its app shell (and to help the site avoid going crazy with push notifications and background syncs to mitigate the latency and avoid Flash Of Stale Content on startup)[1], then from Firefox's perspective AIUI, we want to hang the info about the request off the registration.

This is because we currently always have the registration around and can probably keep it that way at least on an a top/recent basis for small requests.  Anything more than that currently involves us opening per-origin data which means doing a non-trivial amount of I/O that is either explicitly or implicitly serialized behind other I/O.  We ask our quota manager to open the origin's directory, we open API specific SQLite databases for each origin, etc.

If we had declarative routing, we could probably just extract this information up out of the routes as an optimization.  And I do believe it could respond faster in many other more generic cases than we could spin up a service worker and load its routing polyfill; just not as fast as a specialized thing hung off the registration.  My main concern about the declarative routing is that it seems like a huge chunk of API surface that it's premature to standardize right now, and unrealistic to expect Firefox at least to get to in the short/medium-term based on our focus on non-polyfill-able APIs and our multiprocess priorities.

I think we could get to a more targeted mechanism hung off the registration sooner, but it's definitely possible as what amounts to a short-term hack it's not worth it and we should wait for declarative routing.

Re: `<link rel="preload">`, I'm not sure how much of its semantics are applicable to the app shell session priming startup case.  It's explicitly about having an existing document context and that seems deeply baked in, but maybe I'm looking at the wrong thing? (http://w3c.github.io/preload/).  Otherwise, I do agree it makes sense to try and leverage existing semantics specified by existing specs.

1: And I do think this is a very important use-case.  I previously worked on Firefox OS apps, primarily email.  Despite our offline/client-side bias, the name of the game was always minimizing the time to useful content.  Since anything the server doing is inherently parallel, it's a major win to notify the server before becoming blocking on local device I/O which can exhibit variability from contention.

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