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.
Comments
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.
With HTTP/2 server push, there is no difference between acquiring the html and the critical resources. They all get sent without a round trip.
Then there is no latency benefit from requesting in parallel, because there is no round trip to avoid.
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.
Yeah, it would be quite a feat for an http server to force another http server to inject content into it's TCP stream :P (aka, cross origin)
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.