Write a post

HTTP/2 Performance Anti-Patterns

Published Apr 26, 2017Last updated Jun 05, 2017
HTTP/2 Performance Anti-Patterns

Not too long ago, I developed a PHP framework extension which focused on performance, specifically, HTTP performance. Its job was to concatenate stylesheets and JavaScript files. This technique was considered a best-practice because it significantly reduced page load times. But since the only constant thing in life is change, things have changed.

Lets welcome the game changer: HTTP/2 is a major revision of the network protocol which powers the World Wide Web. The specification has been published in May 2015 and has since seen wide adoption: according to Can I Use, over 80% of todays browsers support HTTP/2. That's a very good thing, because your life just got easier in regards to web performance optimization. The reason is simple: HTTP/2 was developed with performance in mind. Lets have a look at yesterdays HTTP performance best-practices and future anti-patterns.

Asset Concatenation

Before HTTP/2 came along, it was very beneficial to combine all your assets into a single file. Since most browsers only allow around 6 simultaneous connections to the web server, serving 100 asset files over HTTP/1 quickly saturates that limit. Requests for asset files are queued up and visitors have to wait. Since HTTP/2 can load multiple files simultaneously over just one connection, this optimization is no longer required most of the time. In fact, serving concatenated assets over HTTP/2 can decrease performance: changing a single line in an asset file invalidates the whole concatenated asset package in the browser's cache. On top of that, the browser has to wait before the complete asset package is retrieved before any code processing can occur.


Similar to asset concatenation, inlining scripts and stylesheets reduces the amount of requests which have to be made to the web server. Like asset concatenation, this is no longer beneficial when using HTTP/2, for many of the same reasons.

Domain Sharding

As previously mentioned, most browsers only allow around 6 simultaneous connections to the web server. To overcome this limitation, websites can serve assets over different domains. If you use 3 different domains, all the sudden you have around 18 simultaneous connections ready to serve. In the days of HTTP/2, this has detrimental effects on performance. Since HTTP/2 serves multiple assets simultaneously over just one connection, what used to be an optimization, now decreases performance and increases complexity: with multiple domains, the browser has to create multiple connections and won't be able to reuse a single connection.

Evergreen Performance Optimizations

While HTTP/2 does make concatenation, inlining and sharding mostly unnecessary, you should not abandon other performance best-practices.


Content delivery networks are still very useful, even though HTTP/2 has eliminated the need for domain sharding. With the use of CDNs, you can decrease latency for users all over the world. If your web server is in the U.S. but your visitors in Europe, a CDN can decrease page load times since the communication does not have to cross over 3'000 miles of water.

Minification & Compression

Transmitting 100 kilobytes is still faster than transmitting 2 megabytes. Minification and compression of assets significantly reduces how many bytes have to go over the wire.


Transmitting nothing is still faster than transmitting something. For this reason, appropriate Cache-Control headers should be used to leverage browser caching.


While not concatenating assets in an HTTP/2 environment will have many benefits, there is one thing to keep in mind: Compressing a single concatenated asset file is more efficient than compressing 100 files individually. This is usually not a problem since the other benefits outweigh a few more kilobytes here and there. However, concatenating might be a useful consideration if you see significant increases in transfer size. You will have to decide what significant means to you and your visitors.


You might be wondering how you can test whether your website is already using HTTP/2: this can easily be accomplished with an online HTTP/2 test tool. You can also check out the HTTP/2 implementations wiki to get a comprehensive overview of web servers which support HTTP/2. Please note that HTTP/2 is not enabled by default on most web servers at the time of this writing.


HTTP/2 has made some of the most complex performance optimizations mostly unnecessary. In fact, continuing to use those "optimizations" with HTTP/2 can decrease performance. If you can use HTTP/2 today, bring back some more simplicity and increase performance by avoiding asset concatenation, inlining and domain sharding.

I create things that help you experience freedom in life. Check out my website to learn more. Live long and prosper!

27th of April 2017: Added additional section with tips on how to start using HTTP/2.

26th of April 2017: Caveats sections was updated to better outline that small increases in transfer size are usually not a problem.

Discover and read more posts from Toby Giacometti
get started
Enjoy this post?

Leave a like and comment for Toby

Gabiriele Lalasava
3 months ago

What servers support HTTP/2? Does Apache, Nginx, Node.js need specific configurations or is HTTP/2 enabled by default? It would be nice to have a note on how to ensure you’re serving assets over HTTP/2 and actual profiling data.

Toby Giacometti
3 months ago

Thank you very much for your input! I have just added a new section (Servers) to the article which should address your points. Let me know if you have any more questions.

Subscribe to our weekly newsletter