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

@bmaurer

> A site might gradually use sw for only parts of the root document

This is why we need a routing approach. Making all-or-nothing behaviour changes doesn't fit into this gradual model.

> So in my mind an ideal solution here would be that a service worker that does nothing, has no cost

Like I said in https://github.com/slightlyoff/ServiceWorker/issues/920#issuecomment-229015463, the spec already caters for this, and impelementation is in progress.

> The cost of having a route that uses the cache and then fetch should be nearly identical to a site which doesn't use SW at all.

Seems fair. It certainly shouldn't be slower than appcache.

> A sw should be able to have some state that is sent with a declaratively specified fetch. Eg, last cached feed story time.

Do you need something beyond `last-modified` or `ETag`?

> It might be nice if the declarative post can be a POST request that is incomplete. That way once the SW starts up it can add more data to the post but the server can start processing

This seems like a separate thing (it's the first time posting has come up). What problem is this solving? As in, when would you want to POST along with an initial navigation? Related: there is a [rough plan for background posting/downloads](https://github.com/jakearchibald/background-cache). 



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