[CognitiveLens]

This info is in some replies further down the page, but just to highlight: your optimized HTTP1 markup will not be slower when you move it to HTTP2, but when you're on HTTP2, you might get even more speed benefit by structuring things differently.

A reluctance to change your markup should not be a reason to resist a change to HTTP2, if and when it is actually available.

[matt_kantor]

I think I'm missing something here. By "markup" do you mean the content of text/html response bodies? By "optimized HTTP1 markup" do you mean minified HTML?

[thomasfoster96]

I think what is meant is that a lot of HTML. Is written assuming concatenated assets, image sprites, CDNs, etc., but a lot of this redundant now. Http/2 might mean a rewrite of you html is required, not just changing some things on your server.

[matt_kantor]

Even if you decide to de-concatenate some CSS and JavaScript files and serve them from the site's main domain, the changes to your HTML will be minuscule (some extra <link>/<script> elements and changes to some src attributes). The bulk of the changes would occur in the linked assets themselves.

I guess if you're embedding data URIs in your HTML to cut down on requests and you want to switch them to normal HTTP URLs then there could be nontrivial markup changes, but I hope it's not common for web developers to do such things by hand.

I think the word "markup" just threw me off. If you replace it with something more general that also covers CSS, JavaScript, images, etc then I wholeheartedly agree with CognitiveLens's comment. The point is that you shouldn't be afraid to throw away obsolete performance hacks if it increases developer productivity and/or leads to a better experience for your userbase.