- From: Jake Archibald <notifications@github.com>
- Date: Tue, 05 Jul 2016 03:20:08 -0700
- To: slightlyoff/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc:
Received on Tuesday, 5 July 2016 10:20:36 UTC
@bmaurer hmm, so there's a problem with both my & @slightlyoff's proposals for this use-case. The preloaded response that ends up in the navigation's fetch event, is actually intended for a future subresource fetch. Both designs put you in a situation where you'd have to pass the preloaded response into the global scope and hope it's still there when you need it. This is really hacky, and would break if a browser ever spun up multiple instances of the SW for parallelism (there's no plan to do this, but it'd be nice if we could at some point). It feels like `<link rel="preload">` has the right behaviour aside from happening too late. So the solution could be routing + a list of resources to preload, which would be satisfied by their own routes. Something like https://gist.github.com/jakearchibald/4927b34bb14c3681a3c1c1ce6ede5b09/cb8328fee735414ced91ff38617b48f73cfb0a1f? --- 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-230441406
Received on Tuesday, 5 July 2016 10:20:36 UTC