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

@annevk 

> Isn’t each GET bavigate going to be wasteful and encourage a more complicated pushState() navigation scheme for subsequent navigations?

This feature will be opt-in, and includes the setting of some headers. A well built server could return an empty response for the preflight. Sure it's more wasteful than nothing, but it isn't much. I think there's potential for browser optimisation here too. If the concurrent fetch's response body isn't read by the time `respondWith` & `waitUntil` resolves, the browser can cancel it.

@bmaurer

> Realistically I think a complex application will still end up using pushState rather than doing fresh navigations on each page view

I hope we can tackle this at some point. I hear developers going down this route because they want transitions, but it seems a shame that they have to reimplement the whole navigation state thing for that. At some point I hope we can look at navigation transitions again.

I know it isn't a complex app, but I wouldn't go `pushState` on my blog, but I would use this concurrent fetch feature. With `pushState` I'd lose all the performance I get through progressive rendering - although we could fix that by exposing the streaming parser to pages.

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