It’s been around two years since HTTP/2, the latest revision of the HTTP protocol used by the World Wide Web, was first published. Providing increased transfer speeds without blocking, extra security and true multiplexing, HTTP/2 enabled servers are able to deliver websites several times faster than those running on the HTTP 1.x protocols.
At Impression we’ve been constantly innovating in our DevOps function and have integrated this technology into our workflow.
All major web server operating systems now support HTTP/2 and all major web browsers are capable of rendering it. But, as of August 2017, only 16.4% of the top 10 million sites support HTTP/2, and this figure is growing at a snail’s pace of <1% of sites per month at the moment.
And it’s simple to configure. The good news for administrators is that if you’re already running an operating system supporting HTTP/2, it’s simple a case of enabling it in your configuration to quickly acquire speed benefits. If your users’ machines do not yet support the new protocol, their experiences will not be affected.
Faster sites are known to have better conversion rates and better Google rankings. Do not miss the opportunity to make this simple change. Users will thank you and the impact on a site’s bottom line can be significant.
What is HTTP/2?
HTTP/2 is a major revision of the HTTP network protocol used by the internet that has changed the way that data is transported between client and server.
First published in May 2015, HTTP/2 overcomes a number of the limitations of HTTP 1.1 – it allows for multiplexing and uses fewer connections between browsers and servers. And, as browser vendors have chosen only to support it over secure connections, moving towards HTTP/2 also means going HTTPS (which is a great move to make regardless).
As web pages and web apps are becoming more and more complex, the physical size of a web page has greatly increased over the past 15 years. The complexity of today’s apps results in a bigger web pages that contain more components HTTP 1.1 was standardised 20 years ago and is no longer able to efficiently render these apps and pages at a satisfactory speed.
A Google-backed technology called SPDY was introduced a few years ago to bridge the gap between HTTP 1.1 and the requirements of modern applications, but this has since been deprecated in favour of HTTP/2.
SPDY enabled some of the great features of HTTP/2, such as multiplexing, compression and file prioritisation, but it depended on a particular set of scenarios on the web server and the user’s browser in order to function properly. HTTP/2, being a widely adopted standard, now addresses these requirements properly.
HTTP/2 benefits overview
There are three main benefits of HTTP/2 over HTTP 1.1:
Multiplexing
Multiplexing is the combining of multiple requests over one connection between a client and a server.
Unlike HTTP 1.1, which requires multiple connections between the client and the server to render a webpage’s multiple requests, HTTP/2 requires only one TCP connection between client and server and all requests share this single connection. When the connection is formed, information such as the number of simultaneous streams and stream size is shared, efficiently avoiding the sequencing and congestion issues present in 1.1.
HTTP/2 is a binary protocol and as such the communication between the user and the server is split into streams and frames. Each of these has an ID which can then be used to route the information into the correct streams, which are all received asynchronously. Multiple requests (streams), if required are sent and received in parallel.
Responses are streamed back to the browser, which figures out what is needed and what to provide. Prioritisation also plays a part here in determining which of the individual streams require more computing power to process first.
Server push
Server push reduces the rendering time of a page by sending site assets to the browser before they have been requested. Page load speed is reduced because everything required by the page is already on its way before the client requests it.
If an HTTP/2 connection is already open at the server, then it can read in any additional header “hints”/information and begin to stream these files to the client at the same time. This is useful for every single website, as external stylesheets and script files are compatible with this method of delivery.
Security
HTTP/2 supports faster secure connections without slowing down page loading speed. Like HTTP over TLS (you might just call this “SSL”), HTTP/2 requires the use of a TLS certificate and the usual connection and handshake process.
HTTP/2 enforces a minimum security version of TLS v1.2 and the TLS connection must also support SNI.
This additional security requirement is another benefit of the protocol’s adoption – as it forces compliance of general good practise, which isn’t difficult, considering even Let’s Encrypt (a free TLS/SSL certificate provider) can support this requirement.
Looking ahead
The way that HTTP/2 has been built is future proof. It will be suitable for some time and will scale with the demands of the growing web. There will undoubtedly be increased compression available on market in the future, and with widespread browser and server support available it’s easy to see how HTTP/2 will be rolled out as the standard for web communications.
As many large websites have not yet adopted HTTP/2, there is plenty of competitive advantage available for more nimble companies to reap the rewards of immediate implementation.
There really is no downside, so it’s certainly our recommendation to adopt HTTP/2. What are you waiting for?
