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

I had a chat with @n8schloss & co and have a much better handle on the problem.

Their fetch event does something equivalent to this:

1. Request page header from cache
1. Request data from server
1. Create readable stream & respond with it
1. Pipe in the header
1. Pipe in the data once it arrives

All my assumptions were based on the simpler shell model where the shell loads then it sets about getting data, which isn't the case here (also yay streams!).

My idea around reusing `<link rel="preload">` semantics but allowing the request to start before the document *does not work*, since the preload cache is per document and this request is being used entirely in the service worker.

Making the preload available along with the navigation request works here, since it's being piped into the navigation response. However, this doesn't really work with the simpler shell model, where you're left with a response that you don't need yet. Best you can do is throw it into the global scope and hope for the best.

They also want to be able to set headers on the preload request outside of the SW lifecycle (such as "last post received timestamp", so setting it via the activate/install event is not the solution. Cookies aren't the prefered way of doing this, since there's no cookies API in SW, and having that data hit the server for other requests is undesirable.

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