Re: [w3c/ServiceWorker] Making a concurrent request for navigations (#920)

@wanderview, our in the field data is still showing fetch from service workers as much slower than fetch from the window (at least for Chrome). In Chrome this will likely be the case until crbug.com/450471 is solved. In addition to the perf benefits, there are also UX benifits to not responding to fetch from the SW. Many browsers will not show the default error page when there's a network error given to respondWith. The browser network page is going to be much much more useful that anything a developer makes to indicate that something is wrong with the user's network setup (and I think it's somewhat unreasonable for most developers to have to make an error page for each error condition that could happen anyway).

That being said, for us, we're likely going to always enable preload, so this is not an issue for us right now. But by not having a way to get this info synchronously we're limiting the flexibility of the api and maybe making it hard for other developers and could be hurting things that we want to do in the future. When the browser is dispatching the fetch event it should already know if it sent a preload request or not, so it doesn't seem like a huge deal to make that info available to developers.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/920#issuecomment-256097596