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

@slightlyoff 

> My largest concern about the declarative proposal here is that it's a high-level, open-ended design space which is something we've decided in the past not to attack without lots of evidence of need

Both proposals are declarative. With your proposal you're declaring that an additional request should happen along with navigations, and it should have particular headers.

> While I accept the critique that this may be scenario solving to some degree

It's trying to scenario-solve, but it's missing the mark. You're creating a preflight for the navigation request, but you're already hacking it to return different data.

I agree with @annevk that I'd like to hear more from other vendors on this, but if we're going to continue to throw around ideas we can't forget about the problems actually being presented:

Without SW:

1. Navigation request made - Facebook may return a generic response, but can start preparing user-specific parts
1. Wait for renderer & response
1. Page starts fetching user-specific bits

With SW:

1. Wait for renderer & service worker
1. Return cached response, but also ping Facebook so it can start preparing user-specific parts
1. Page starts fetching user-specific bits

If I'm reading @bmaurer correctly (correct me if the above lists are wrong), the problems are:

* SW startup adds significant delay to a cached response
* SW startup (and therefore renderer startup) adds significant delay to the Facebook ping

I don't think we should try and solve these with one function call. There's two parts there, avoiding SW startup for handling responses, and providing some kind of declarative preload (maybe multiple, maybe not to the same URL).

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