To be clear, my squabble is not an argument against SW in any way. SW affords a lot more control to the developer and makes this pattern significantly simpler to implement and deploy.
I'm simply pointing out that you can get most (if not all) of the claimed perf benefits using existing API's. Yes, it won't look as pretty, but if you want to deliver a better experience to existing + older browsers.. this is something to consider.
As a person who has spent weeks of my life trying to persuade AppCache + HTTP caches to do what I want (and who subsequently became a champion for the low-level primitives that became SW), I just don't agree with this.
It seems true in principle, until you try to actually get precisely the semantics you want, and then things go downhill fast. People should definitely try to find ways to use the HTTP cache more aggressively, but in practice, it's a giant slog with very little cross-browser consistency and total failures on mobile devices.
We should be thinking about how to deliver the best of both worlds: a great experience for older (non-SW) browsers, and an even better experience for those that do. The underlying patterns are effectively the same, SW just makes many things much simpler, and there is no reason to block on SW to start on this path.
No, HTTP/2 has no effect on this. The insight here is that we're initiating the fetch for the HTML and its critical resources in parallel... which requires that the page initiating the navigation knows which critical resources are being used on the target page.
But isn't HTTP/2 push restricted to same-origin content? Critical resources may not be same-origin, so I'd expect this technique to have some utility even when HTTP/2 is fully deployed on clients and servers and fully utilized.
Actually, you're both right. With http/2 the server can push critical assets delivering similar results. But, that requires that the server supports http/2 and is smart enough to initiate the push, AND those resources are same-origin.
The benefit of above technique is that it's deployable today, doesn't require the destination server to be upgraded, and works for cross-origin resources.
Cross-origin could be an HTTP server itself serving content from a different origin via a push channel (which it could do either because the different origins share servers -- which can occur -- or by having, e.g., prefetched the data itself from the foreign server and pushing it.)
HTTP/2, I'm pretty sure, doesn't allow this (and there are all kinds of reasons it wouldn't be a good idea), but it wouldn't necessarily require forcing the other server to push the content.
The early feedback from FF, IE, (and to some extent, Webkit), folks have been positive, and I'm hoping this can be a cross-browser feature in 2015 (yes, I'm an optimist).
Let's hope that twelve months from now, we're looking at a very different landscape. Kudos to NYTimes for issuing the challenge. At the very least, this is an important conversation starter.
