While HTTP/2 will lead to some huge improvements in efficiency it's going to take some time for the web to collectively forget a decade's worth of kludges otherwise known as 'best practices.'

Domain sharding, image spriting, script concatenation, lots of unnecessary intermediate caching, etc. All of these were created with one goal. Faster page load times (via connection thrashing) meant more Google PR juice. All of them have hidden costs that add to development complexity and unnecessarily increase load on the servers-side. IMHO, all should die a fiery death.

If we're really shooting for a faster and more efficient web experience, HTTP/2 solves the greatest constraint on the back-end (ie allowing multiple connections over a single TCP stream).

What we need next are a change in priorities defined by a new standard of 'best practices' such as:

1) Stop concatenating scripts

Assuming HTTP/2 and no 1 request/asset constraint what's the point? Sure, it may lead to to a 10-20% increase in compression overall but only if the user navigates to every page on your site.

2) Stop minifying scripts

Controversial? Maybe, but why are we intentionally creating human unreadable gibberish for a modest gain when intermediate gzip compression leads to much greater gains.

I can't count the number of posts I've read where a developer goes gets excited about shaving 40KB off of their massive concatenated global.js soup (incl jquery, mootools, underscore, angular, etc) when they would have had much greater gains by optimizing image/media compression.

As a library developer, minifying sucks. For every version I release I have to produce another copy, run a second set of tests (to make sure minifying didn't break anything), and upload/host an additional file. In addition, any error traces I get from users of the minified version are essentially useless unless they take the time to download and test the non-minified version.

3) Quit loading common libraries locally

If I could teach every budding web developer one lesson it would be how a local cache works and how no variation of concatenation/compression will lead to a faster response than a warm cache.

Yes, loading 3rd party code can potentially lead to a XSS MITM attack (if you don't link via HTTPS). No, your local copy is not more robust than a globally distributed CDN. No, loading yet another unique copy of jquery is not going to be faster than fetching the copy from a warm local cache.

The only justification for loading common libs locally is if the site operates on an air-gapped intranet.

Google indirectly encouraged most of these 'best practices' by giving PR juice to sites with faster page load times.

It would be really interesting to see if/how the search engines will adjust their algorithms as new 'best practices' are established. I know they're starting to incentivize sites that use HTTPS.

What I'd really like to see is sites being penalized for making an unnecessarily large number of external domain requests with the exception of a whitelist of common CDNs.

As for TCP/IP. I'd really like to hear a sound technical justification of why the header checksum calculation for TCP is coupled to the IP header.