HTTP (or HyperText Transfer Protocol) is the protocol which manages the connection between your server and the clients’ browser. The first and the oldest HTTP protocol was described in 1991. At present we are using its updated version HTTP/1 which was released in late 1999. However, nowadays more and more web developers are talking about the necessity of switching their websites to the new HTTP/2 protocol.
So what is HTTP/2 and why do we need it?
Time for Changes
The reason why we have to change HTTP/1 into HTTP/2 is rather simple: HTTP/1 is too slow for modern websites.
Back in 1999 the website design was rather simple. You could place some text, several images and, maybe, a banner ad on your web resource, so your website was rather quick in downloading. Nowadays, according to Daniel Sternberg a mediocre web page requires 1,9 MB of data to be downloaded from nearly 100 different web resources (including, pictures, fonts, js- and css files).
Unfortunately, HTTP/1 can’t download information from different sources at a high speed and this was the main reason why HTTP/2 was designed and released.
Some Historical Facts
The first idea of speeding up HTTP/1 appeared in 2007, when the first working group named HTTPbis was formed. In 2009 two Google engineers released information about their new SPDY project, which became the frame for the future HTTP/2 protocol, and the HTTP/2 development started with using SPDY/3 foul copy.
In April, 2014 Daniel Sternberg published his well-known document called ‘http2 explained’, where he gave a detailed information about HTTP/2 and the reasons of its development. In 2015 the new version of HTTP was affirmed at last and the process of its infiltration into the world wide web has started.
At present, most of web-servers (Apache, Nginx) and browsers (Chrome, Firefox, Opera, Edge, Safari) are able to support this protocol.
According to the latest statistic data released by W3Techs in April 2016, nearly 7.1% of the top 10 million websites support HTTP/2.
The new protocol for hypertext transfer can be characterized by the bunch of pros:
- Header compression
- Dependencies and prioritization
- Server push
Multiplexing can be called a real benefit of the new HTTP/2 protocol. Thanks to this option more than one web element can be requested and received at the same time. All requests and responses are broken into pieces called frames. These frames usually contain meta information which identifies what request/response they imply to. Due to this fact, the requests and responses are overlapped on the same connection without causing confusion and can be received in whatever order the server can respond with.
All in all, multiplexing is really able to hasten the page load and render time.
Headers are the meta information with the help of which the browser ‘tells’ the server what it wants and is able to accept. The nature of the headers is stainless: they don’t change much between requests. This the main reason why numerous redundant bytes are created.
HTTP/2 is able to compress all this excess information. The combination of Huffman encoding and lookup tables usually reduces the number of bytes sent in a request down to zero.
Dependences and Prioritization
As HTTP/2 hastens the process of data interchange between the server and the browser in several times, a new challenge may be arisen. For instance, there is a great possibility that the most important information won’t be delivered from at first and the page performance will be reduced. In order to avoid all these difficulties, the web designers have built in the ability to address it in the protocol.
Thanks to priorities listing and objects dependence, the server is able to ‘understand’ that the critical data is sent to the browser correctly.
Server Push is a unique option which can be found only in HTTP/2 protocol. If you want to improve your downloading time, you may ask the server to send a certain object to the browser beforehand, and this what Server Push actually does. It’s a little bit tricky, because the server needs to know what the state of the browser cache is and what what object the user will need next, so new innovations and creations are expected in this area.
HTTP/2: When to Join?
The introduction of the new HTTP/2 protocol doesn’t certainly mean that you should change your old one in a rush. For instance, there are loads of websites which continue to use HTTP/1.1 and don’t want to make any changes. At the same time, more and more web resources’ owners choose exactly HTTP/2, and this will make HTTP/1.1 sites slower and slower in a certain period of time.
If you aren’t ready to change your hypertext transfer protocol at present, you may still make some changes in order to prepare it for the future change. For instance, you can continue to unite the images into the sprite files, give up building-in images from DataURI and stop domain sharding.
In case your web resource features a great number of the mobile traffic, then you should join the new protocol as soon as possible.
If your customers or visitors usually open your website with the help of their smartphones and tablets, they will notice speeding of your web performance nearly at once.
Since the middle of November 2015 CDNsun has transferred all its HTTP CDN services (CDN Static and CDN Push) into the new HTTP/2 protocol.
For instance, our Online HTTP/2 protocol support test is able to reveal whether your website is compatible with the new HTTP/2 protocol without SSL encrypted connection.
Online HTTP/2 protocol speed test gives you a nice opportunity to compare your HTTP/1 speed content delivery with the HTTP/2 one.