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

Speaking as a Mozilla SW dev focused on @bmaurer's use case (and with less wisdom than @wanderview), what if we hang a "session priming request" off the ServiceWorker registration?

General operation:
- The ServiceWorker is able to set and update a *small* request off its registration that it can freely update with best-effort persistence but no transaction semantics or durability guarantees.
- When a navigate request is triggered it necessarily gets run by your ServiceWorker registry to determine whether to intercept or not.  If it matches, meaning it will be controlled by the ServiceWorker:
  - If there is no suppression timer, the session priming request is triggered as a "no-store" request, helping establish a network connection and delivering the needed cookie-ish identifier to the server so it can start doing database loads and whatever processing is needed in parallel with the browser's SW load.  This starts a session clock suppression timer so every navigation request doesn't generate wasteful spam.  Timer interval can be specified by the SW to best match the server backend with some sanity clamps by the browser, and/or dependent on the lifetime of the HTTP/2 connection.
  - The ServiceWorker is spun up like usual.
- If the server has data it knows the ServiceWorker will want, it uses HTTP/2 Server Push to push the data into the network cache.  The SW can fish the data out of there and it's the cache's problem to unify races between the SW requesting something and the server pushing it.  The SW does not need to be aware of special types of requests like preflight requests.

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