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

So to respond to @jakearchibald's comment above.

> When the user navigates to my site I want to ping a URL with some sort of credential. I'm happy for the actual navigation request to go through the service worker and therefore be delayed by it starting up, but the ping should not depend on SW startup.

I'm not sure what you mean by ping, do you mean hit a url and be able to access it's response from the SW or something else?

In our use case and I suspect many others we're going to be caching most of the page shell and responses from our servers to service workers will return structured data. For Facebook if we measure the time that it takes to show newsfeed a lot of this time is blocked by fetching the data on our backend, and if we look at how long it takes to start service workers then the delay introduced by having them on the critical path introduces an overall regression. This kind of API is the best solution for this problem imo, the service worker stays in charge and still can construct responses, but hitting the backend isn't blocked on the service worker starting. I suspect that for most sites this will be a common use case, you'll want to cache most of your site but you still want to have content as fresh as possiable as quickly as possiable.

I think it's also okay for preflightRequest to be optionally there or not, this way if the SW is indeed started and it wants to add extra data to headers or make a request to a different endpoint all together it can. But if the SW is not started it only get's to add headers (and maybe change some other fetch options).

> When the user navigates to my site, I want a network request for the navigation to race SW startup & response. If the SW manages to win, at least the network request served as a ping.

Nope, we ultimately want to reply with just the newsfeed content as structured data. We want the SW to be able to get this and then turn it into the webpage. We always want the service worker on the critical path in this case.

> When the user navigates to my site I want to perform a series of network preloads while the SW is starting up

So right now we'd just want to do one preload before the sw starts and then be able to access its response in the fetch event.

> For particular requests (depending on URL, type, & headers), I want to declare the behaviour (serve from cache, serve from network) up front so the browser can handle particular requests/responses without starting the SW

Nope, at least right now we're never going to respond just from cache and will always have a hybrid kind of approach where the service worker constructs a response from both cache and network.

I could see that others might find this useful though and I bet that down the line this would be useful for us as well, but this kind of declarative routing could also totally work with preflight request and it also doesn't solve the same issue that preflight request solves. 

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