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