Given this article is about how you can improve _your_ response times, I think the author and audience probably have the the ability to implement HTTP2.

That can be fixed just as easily as reducing the number of requests.

Adding http2 is easier then reducing the number of requests.

And infact reducing the number of requests using things like spritemaps, bundling js and css is actually an antipattern with http2.

> And infact reducing the number of requests using things like spritemaps, bundling js and css is actually an antipattern with http2.

Those are just ways to lose some of the impact of bloat without addressing the bloat itself.

If you address bloat directly it will benefit all users.

If you shard on http2 it will take longer since now it makes multiple ssl connections which have have the ssl handshake.

With http2 it's all multiplexed into one connection. So you have the one ssl connection, but that one connection has multiplexed connections inside it. And since it's one tcp, the tcp sliding window has opened up and is actually faster then opening a new tcp connection.

If you migrate to HTTP2 or move to a host that already supports it then cutting down on "round trips" is an obsolete concern altogether.

HTTP2 does not magically bundle all connections to one. It still very much depends on how you build up your page.

It does not magically split one connections into many. One domain == one connection. Sure it won't undo your "domain sharding" hacks and merge your CDNs, yeah :)

yeah, but we're talking about what website operators can do to speed up their site. you can try to dramatically reduce the number of files you need to send. OR, you can just enable HTTP2. HTTP2 seems like a more simple answer.

HTTP2 doesn't magically change the number of hosts you communicate with (CDNs, ad networks, tracking providers, etc) and most importantly, it doesn't reduce the amount of shit developers are piling onto web pages.