Improving web performance with HTTP/2
In our ever-evolving digital ecosystem, there are plenty of technical developments that arise that cause excitement and anticipation among developers. However, this excitement is often tempered by the realization that these advances are not currently supported. Developers discover that although the development will make both their lives and their clients’ lives easier in the future, it won’t be able to help them in the present.
Yet, HTTP/2 is not one of these examples. Already widely available, it’s a tool that can be used right away to improve web performance. Announced in 2015, the coverage for HTTP/2 is already at 83% and growing among browsers. With this in mind, now is the time for developers to begin embracing HTTP/2, and to move away from HTTP/1.1.
But what is it exactly that sets HTTP/2 apart as a noticeable technical improvement?
The merits of HTTP/2
To begin with, performance with HTTP/2 is much improved. Tests have revealed that HTTP/2 was able to take advantage of multiplexing, delivering webpage resources from the server in less than a second, compared to more than 1.5 seconds for the same web page with HTTP/1.1. This increase in speed reflects the benefits of fragmenting the resources available with HTTP/2. In order to further explore the benefits of HTTP/2, we can analyze a digital transformation project Netcentric undertook in partnership with a major car manufacturer.
HTTP/2: a case study
Typically on a project such as this one, using the HTTP/1.1 setup, developers would set the definitions for each component. Then they would compile them into a one large file. This means when a user visits the page, this one big file must be sent from the server to the browser. However, to embrace HTTP/2 best practices it should operate differently: the developer would have the same files, but would alter the process so that they are compiled independently. That means that when a user visits the website, definitions will be delivered into independent files per component. So, for instance, if a page had four components, then just the definitions for those four components would be sent, rather than definitions for the whole website (including components that are not necessarily being used or needed at the time).
In other words, on a project like this one, the process is much more streamlined and efficient with HTTP/2. In this case, Netcentric took the following steps to implement HTTP/2.\
- We started by defining the concept and specification.
- Then we developed an initial PoC with two components, to confirm our concept is working correctly. This step included updating CSS filenames and folders under the new convention, modifying the Gulp build task to create separate CSS files, implementing and refactoring watchers and other tools to work with the new Front-End build, configuring each component’s AEM clientlib category, and updating each component’s HTML with a CSS clientlib call.
- Following this we carried out a general roll-out of the rest of the components across three different sprints, in order to gradually implement the changes and fix any issues encountered along the way more easily.
Challenges and benefits of HTTP/2 in this case
We faced some issues during the implementation phase, including the case when a component’s code (definitions declaration included) was being moved within the DOM. Furthermore, there was also the case where some CSS file definitions were duplicated because the same component was used more than once per page. When it came to testing, AEM’s HTTP/2 support was limited to AKAMAI, and while there are some external tools like Google page speed check, we were not able to use them as development servers were behind passwords and credentials.
However, there were plenty of tangible benefits from using HTTP/2 during this project, perhaps the most important of which were related to performance. The file size was significantly reduced with HTTP/2, while the download time was almost halved. There were also benefits around component-level cacheability. A change to a component’s definition didn’t affect another’s cache. This impressive time-saving is largely a result of the nature of how HTTP/2 works, in that resources can be sent multiplexed into a single connection. In addition, we tried to reduce the size of each individual file, which is considered best practice with HTTP2.
Ultimately, this project highlighted to us the potential of increased efficiencies with HTTP/2. Largely these improvements come back to the idea that individual components can be updated. Therefore, when a client visits the site, it’s just the single relevant component that is updated, as opposed to the entire website’s definition. As a secondary benefit (which cannot conclusively be attributed solely to the switch to HTTP/2), analytics for this project suggested that the average time for site visits during the period was higher than it was before. However, it’s predominantly in the areas of speed and performance in which we experienced positive results out-of-the-box. The switch to HTTP/2 is a more methodical task than reengineering. We believe that CSS would be a good starting point to introduce modularization in a project and then later move onto JavaScript and sprites.
Conclusion: embracing HTTP/2
HTTP/2 should be embraced right away to improve performance, as well as the general efficiency of projects. The set-up of HTTP/2 allows for greater independence of files, so that only those which have been modified are sent to the browser. This results in a much more streamlined and fluid experience, which saves time for the developer and the client. And unlike some other technical advances where we can only imagine the potential benefits in the future, HTTP/2 is already widely available to help implement greater efficiencies in the present.