Undoing Years of Optimisations With HTTP/2

Want to help support this blog? Try out Oh Dear, the best all-in-one monitoring tool for your entire website, co-founded by me (the guy that wrote this blogpost). Start with a 10-day trial, no strings attached.

We offer uptime monitoring, SSL checks, broken links checking, performance & cronjob monitoring, branded status pages & so much more. Try us out today!

Profile image of Mattias Geniar

Mattias Geniar, December 26, 2014

Follow me on Twitter as @mattiasgeniar

Someone just released an HTTP server called H2O, which is significantly faster than Nginx (especially for small files). This in itself is an accomplishment, but the reason for this development is even more important.

Current techniques used to decrease the number of asset files (e.g. CSS sprites and CSS concatenation) becomes a drag in page rendering speed in HTTP/2.

Such techniques were beneficial in HTTP/1 since the protocol had difficulty in utilising all the available bandwidth. But in HTTP/2 the issue is fixed […]. Instead, switching back to sending small asset files for every required element in the webpage being requested, becomes an ideal approach.

Kazuho Oku

Indeed, SPDY/HTTP/2 introduces a far more efficient approach to loading css/js/images/… concurrently in a preferred order, which could mean having a small number of larger files could be a less desirable approach.

Since SPDY is already up-and-available (and powering this blog), I’m sure it’s only a matter of time before someone does some real-life browser testing with a small number of large files vs. a large number of small files on a website.



Want to subscribe to the cron.weekly newsletter?

I write a weekly-ish newsletter on Linux, open source & webdevelopment called cron.weekly.

It features the latest news, guides & tutorials and new open source projects. You can sign up via email below.

No spam. Just some good, practical Linux & open source content.