Performance optimization in a HTTP/2 FastComet world

The Hyper Text Transfer Protocol is probably the most used network protocol in the World Wide Web. Over the years we witnessed the milestones it reached, its up and downsides and of course how it evolved. The latest update of that protocol brought the HTTP/2 version to the field and it is full of innovations, new and improved features and even better security level. But how did it reached that milestone – That question we will answer in following lines of this blog post!

HTTP 0.9 and HTTP 1.0

The first version of the HTTP protocol was born in the not so distant year of 1991. By that time the protocol was quite innovative, yet simple in terms of functionality. The way it worked was that a line of ASCII characters was passed from a client computer to a server via a single network connection to an IP address and a port. The line contained no headers and it always started with the “GET” word followed by the path to the resource that is requested.

GET /contact-us/

The server then responded with the actual Hypertext Document and then the connection was closed.

Within the next 4 years, the world first popular browser Mosaic was born and with it the need for a more advanced version of the HTTP protocol due to its limitations. So in 1996 HTTP version 1.0 was released and immediately adopted by the major web browsers of that time. The version was introducing Header based Request/Response communication and of course, the Response was no longer limited to only hypertext but it also supported regular files.

HTTP 1.1

HTTP version 1.1 was introduced back in 1997 as a standard update of HTTP 1.0. For the next several years HTTP 1.1 was truly innovative with the support of Keep Alive and of course the Host Headers (allowing for multiple clients to share a single IP address), however, with the increasing demand for more complex and larger in size web pages, the protocol became a burden.

HTTP 1.1 allows only a single request per resource to be made and every request can only be sent over the new connection. This means that if a website loads for example 5 images, 2 CSS files and 2 JS files the client’s browser will initiate 9 requests to the server for static resources and 9 new connections that will have to wait for one another to be closed. Within each request, the browser will send Request Headers and will receive Response headers in plain-text format when the web server sends the requested resource. Each time a new visitor access a website their web browser takes time to send the Request Headers, to receive the Response Headers with the content and finally to render the web page.

Back in the days, the average size of a web page was 15-20 kB which for HTTP 1.1 was piece of cake to handle, however, now the average size of a web page grew to around 2.5 MB and the architecture of HTTP 1.1 makes it obsolete in terms of providing fast loading speed for modern websites.

So the Web was in need of a new network protocol that can actually meet the demands of the modern web pages. Not only that but the protocol should also address the scaling size of web pages in such manner that can be utilized in future no matter the size and a number of requests a web page has.

SPDY

The challenge was big and only Google made a step forward with the development and further implementation of the SPDY protocol. The main goal of that protocol was to speed up the web page loading time and of course to improve the security. This was achieved via three main improvements over the HTTP 1.1 protocol:

  • Compression – The headers were no longer transmitted in plain-text format but instead they are compressed, thus reducing their size dramatically.
  • Multiplexing – A single connection is used for transferring multiple Requests/Responses and of course static resources such as images, CSS files, js files and so on.
  • Server Push – The web server can send additional resources to the client which were not requested by the client’s browser.

The SPDY protocol, however, did not replace the HTTP 1.1 protocol instead it was serving alongside HTTP 1.1 simply modifying the way how Request/Response worked.

All modern browsers immediately adopted the idea of SPDY and released updates for full support of that protocol. Unfortunately for security purposes that protocol was only supported over the https protocol which requires a valid private SSL certificate.

HTTP/2

With SPDY gaining fast adoption rate and of course with clear advantages over HTTP 1.1 the road for HTTP version update was drawn and after brief selection process the SPDY protocol became the very basis of the HTTP/2 protocol.

In May 2015 the HTTP/2 specification was published which marked the beginning of a new era for the Hyper Text Transfer Protocol. Earlier that year Google announced that they will be dropping the support of SPDY in favor of HTTP/2 which on theory boosted the adoption rate of HTTP/2 hoping for all SPDY users to shift over. HTTP/2 is released as a native extension to the HTTP 1.1 protocol which means that it is backward compatible with websites previously working over HTTP 1.1. The intent of the protocol is to be used for websites already build for HTTP 1.1 and also for new websites that will be created around the functionality of HTTP/2.

At this point all modern browsers fully support HTTP/2, however the same as the SPDY – only over the https protocol which calls for an SSL certificate to be installed.

Does FastComet support HTTP/2?

From the release date of the HTTP/2 protocol until now we were experimenting with mixing the HTTP/2 protocol with our already optimized server setup. In many cases, however, the results we were getting were not satisfying mainly because we had to remove certain loading speed optimizing features in favor of HTTP/2. Furthermore, the support of HTTP/2 by cPanel was also delayed. Officially they announced HTTP/2 support before 2 months which was forcing us to believe that it was not the right time to implement it. Until now!

We are happy to announce that the support for HTTP/2 will be available by the end of this week for our customers on the StartSmart and ScaleRight packages. The switch to HTTP/2 will be part of a major web server improvements patch affecting these two packages which will be implemented one server at a time in low traffic times of the day during Thursday and Friday, 5th and 6th of October. The implementation might cause brief service interruption due to the restart of the web server for which we would like to apologize in advance and also thank our customers for their patience and understanding.

After the planned patch is applied HTTP/2 will be activated by default for the StartSmart and ScaleRight packages. As for our Cloud SSD VPS and Dedicated Server customers, we will let them decide whether or not to use HTTP/2 or in other words the implementation of HTTP/2 for these Web Hosting Packages will happen on demand only – by submitting Technical Support Ticket in the “General” category of our Ticketing System.

As for our most optimized Shared Hosting package – SpeedUp RocketBooster, due to the setup of the environment for that package we are unable to provide support for HTTP/2 protocol at this point. However, we would like to assure our customers that we are giving our best to make it possible and as soon as that happens we will release a separate blog post explaining the challenges we are facing with that implementation.

HTTP/2 Needs SSL/TLS

Please be advised that HTTP/2 will be available only over the https protocol since the web browsers will not support it over HTTP protocol. If your website is still not using https – this is the right time to activate it considering the threat of the “Not Secure” sign in Chrome 62. You can do that via the free Let’s Encrypt SSL certificate feature we offer in the cPanel service.

Christopher

Christopher has many years of experience leading teams in the fields of Technical support, Server Administration, and Product Development. He mainly works on the backend, helping to create the infrastructure that powers FastComet. He is responsible for flawless migrations and quick and efficient answers to client questions. He also monitors our network status and jumps in to solve time-sensitive issues like DDoS attacks and stops malicious attempts in their tracks. Christopher’s primarily responsible for making sure that our servers purr along, and has worked tirelessly to improve automation at FastComet.