The HTTP we are all familiar with is now in its way out. While it has done its job quite well for the past few decades, it’s now become inefficient in today’s data heavy websites.

Here are some past techniques (rather hacks) for website design and development for the old HTTP1 that are soon to be extinct:

  • Spriting: taking multiple images, combining them into one image, and using CSS to only show part of that image in a particular place.
  • Concatenating: Taking multiple CSS or JS files and sticking them into one large file.
  • Serving assets from a cookie-less domain.
  • Sharding: creating different domains or sub-domains to host assets like images.

The first two techniques are aimed at avoiding multiple HTTP requests. In HTTP1 a request is a very costly thing and takes a lot of time, each request may be loaded down with cookies that must be sent as part of the request, and none of it is compressed. It’s faster to lump a bunch of things together and get it all done in one go than to keep asking for different resources.

The third technique is used to minimize the time required to get assets; cookies, if set, must be sent to the requested domain along with every request – that adds up to a lot of ‘wasted’ space on the line. If your assets are on a different domain that doesn’t use cookies, then requests for those files won’t need to send cookies with them, and it’s all a bit faster.

The last technique, sharding, is because browsers used to only allow two simultaneous HTTP requests per domain. If you create a new domain for some of your assets, then you double the amount of simultaneous connections the browser will allow in order to get your files. Thus, you can pull the website content down faster. In reality, sharding hasn’t been too useful in the last couple of years because browser vendors decided the ‘two connections’ restriction was daft, and they ignored it.


Here’s some good advice! Do not use those HTTP1 based best practices with a website being served over HTTP2. It also means that all of those HTTP1 performance techniques are harmful. They will make a HTTP2 load slower.

HTTP2 makes the cost of multiple requests far less because of a number of techniques it does itself.

  • It can leave the connection open for re-use for very extended periods of time, so there’s no need for that costly handshake that HTTP1 requires for every request.
  • HTTP2 also uses compression, unlike HTTP1, and so the size of the request is significantly smaller – and thus faster.
  • HTTP2 multiplexes; it can send and receive multiple things at the same time over one connection.

The long and short of it is; when you build a front-end to a website, and you know it’s going to be served over HTTP2 – you need to ensure you’re not using legacy HTTP1 performance techniques that are going to harm the site under HTTP2.

Hope this helps you in your next development endeavor