The Internet as we all know it today wouldn’t have existed without the HTTP protocol. It is the heart and soul that pumps content to all of us. It makes it possible for us to read the latest news, order stuff online, watch videos on YouTube and get to our favourite websites on all types of devices - workstations with 27-inch displays, laptops, mobile phones, tablets and even e-readers that offer browsing capabilities. Sadly, that protocol has not been changed since 1999 when version 1.1 was released so, when HTTP/2 was released earlier this year, it was a source of major excitement. Of course, the SiteGround team has immediately started working on it and we are now happy to announce that all our shared and cloud servers support HTTP/2.
Why HTTP needed an update?
Modern websites/apps make hundreds of HTTP requests and HTTP 1.1 is not well designed for the performance needs of the modern web and the constantly growing requirements of the users. During the last 16 years many new technologies emerged and web developers got really creative in terms of going around and jumping over the limitations of HTTP 1.1. However, it was time for the protocol itself to change and introduce some new features that will speed up all sites on the Internet.
What’s new in HTTP/2?
HTTP/2 is based on SPDY and is focused on performance improvements. It offers the following enhancements:
Multiplexing For Faster Data Transfer
Modern websites/apps require the web browsers to make many request to render a web page. In the beginning HTTP/1.0 allowed only one request to be made via a single TCP connection. With HTTP/1.1 this was addressed so browsers can make multiple requests to load many resources simultaneously. Unfortunately, another problem called head-of-line blocking was not resolved.
When HTTP/1.1 is used the requests flow is usually the following: the browser sends a request and needs to wait for the response of the server in order to send the next request. Modern websites have over 100 objects and even when browsers use multiple connections this way of handling requests can add up a lot of time because of head-of-line blocking.
The solution introduced in HTTP/2 is called multiplexing. It gives us a simple way to request and receive multiple web objects at a time through a single connection. It is the solution for the head-of-line blocking problem. HTTP/2 resolves this problem by using frames. Every frame contains meta information about requests/responses which allows one connection to be used for simultaneous delivery without causing confusion about which response is associated with which request. Here is an example how HTTP/2 handles the same three requests that we showed in the previous diagram:
As you can see from the second diagram when HTTP/2 is used the user sends multiple requests and can receive them in whatever order. Thus, pages load faster. For example, the server needed more time to handle the second request but the delivery of the third object was not blocked.
Compression Of Headers For Transferring Less Data
The second big improvement added by HTTP/2 is related to HTTP headers. Clients use headers to inform servers what information is needed and in what format the information could be delivered to them. For example, a web browser usually sends headers to inform the servers that it supports gzip compressed data. Cookies are also communicated via headers and the size of some cookies can get really big.
The problem is headers do not change much between requests. Also, with HTTP/1.1 headers have to be provided for every single request, which of course is pointless when headers do not change. Now HTTP/2 not only sends headers per connection, but it also offers compression. This means that an average web page that contains ~80-90 objects can now be loaded much faster because the web browser will need just one round trip to send all of the headers for all of the objects.
Prioritization For Proper Page Rendering
The third problem which HTTP/2 solves is caused by multiplexing and headers compression. Some objects are more important than others. For example, the CSS objects for a site should be delivered in the beginning, so that the site could be properly displayed. If multiplexing is used you cannot be sure that the CSS will be delivered before the rest of the objects.
The designers of the protocol, decided to address this issue in the protocol itself. Clients are able to communicate with the server and indicate priorities for certain objects and this way the web servers can make decisions about which objects should be delivered first to the clients. Since the protocol itself supports prioritization this means that web developers should not worry about changes that need to be made to their apps. The modern web browsers will take care of prioritization and handling of data streams in HTTP/2.
HTTP/2 Needs SSL/TLS
All web server implementations support HTTP/2 when it is used over an encrypted connection. This means you need an SSL for your website in order to take advantage of HTTP/2.
You can find more about HTTP/2 here: https://http2.github.io/faq/
Is HTTP/2 already in use?
HTTP/2 is already alive and you have probably already using it on your end if you’re using a modern browser such as all of the latest versions of Chrome, Firefox, Opera and Edge support HTTP/2.
Now all SiteGround shared/cloud servers support HTTP/2. Please note that clients that have private SSL certificates (see above: encryption is a must when HTTP/2 is used) can immediately take advantage of the new cool performance optimizations offered by HTTP/2.