HTTP/2 will make the Internet faster. So why the slow adoption?
Website protocol HTTP/2 image via Shutterstock
Over the past two-to-three years, HTTP/2 has made sporadic news every few months. Recently, CloudFlare — a massively successful CDN and security company — announced it was activating HTTP/2 server push, and several major news outlets reported it as “making the Internet faster.”
If it’s so much faster, why the slow adoption of HTTP/2?
A large player like CloudFlare starting to use server push is huge news, and we’re happy for their great team. But one of the most notable pieces of information in the first article is CloudFlare’s CEO, Matthew Prince, pointing out that the overall change in web performance and the user experience won’t happen overnight.
Well, given how widely spread HTTP is, it’s no wonder moving to a new major version of the protocol is going to take a bit of time. There are all sorts of speed bumps along the way and it takes time for everyone to adapt to how the new protocol works.
The most recent hurdle seen is that Chrome just stopped supporting NPN protocol negotiation in favor of ALPN. ALPN requires the very latest OpenSSL version, which is something few systems in production today are shipped with. Read the article “The day Google Chrome disables HTTP/2 for nearly everyone” by Mattias Geniar for more details.
In general, major browser and server makers are working hard on support for HTTP/2. HTTP/2 is enabled by default in most major browsers today and a not insignificant part of your daily web surfing probably happens over HTTP/2 — well, unless you use Chrome 51 or later — as large players like Google and Facebook support it. The protocol is backward-compatible with HTTP/1.1, and it will soon become ubiquitous when new versions of clients and servers switch it on.
So, why does it seem like much of the web development community (and most of the world) is still largely ignorant about HTTP/2 and what it means for their applications?
Maybe it’s exactly because HTTP/2 is backwards-compatible with HTTP/1.1, which means developers really don’t have to learn anything new to make sure their applications continue to work. There is no fear involved, which always helps when new information has to be spread!
Eventually, people who are ambitious are going to realize that there are speed gains to be made by understanding the protocol, and then they will dig into it and make their applications faster than the rest. This will bother the rest of the community, so they too will dig into it (or at the very least, Google what new libraries they should be using). So, I think it will be OK in the end, but like Matthew Prince said: It will take a bit of time.
The cool thing, however, is that these performance gains are up for grabs right now! So, if you’re a developer looking for an area to stand out, HTTP/2 might be a good option. You can be one of the ambitious ones to create best-practice technology for using the HTTP/2 server push feature. There is a lot of implementation work that hasn’t been done yet!
HTTP/2 vs. HTTP/1.1: A performance analysis
Load Impact has taken a particular interest in HTTP/2 because we love everything about web performance — of course!
When we take an interest in something, we like to study it, and study it pretty thoroughly. So, we decided to measure the performance impact a typical site might get if they switch their data transport from HTTP/1.1 to HTTP/2.
In the study, we took a popular site, downloaded its content, and hosted it ourselves in a controlled environment. Then, we simulated different network characteristics and measured how much performance and user experience differed between the two protocols.
Check out the video above from the O’Reilly Fluent Conference in March 2016 and see the results of the study yourself. You might be surprised at how web performance can improve with HTTP/2 for a typical site out there —and that’s completely without server push, by the way.
A wink of the Load Impact eye to Daniel Stenberg, founder of cURL and libcurl, who has been a great partner with us in our HTTP/2 research. Daniel’s done amazing work with the Internet Engineering Task Force to help architect HTTP/2, so make sure you check out his musings, too.