HTTP 2 Server Push

A year ago, I posted an article explaining the general concept of HTTP 2.0. Today we can finally use it for building websites as it is now supported by major browsers. This article will focus on HTTP 2.0 - Server Push, from what it is, the problems it solves, how to implement it (using commons.host), how to verify that it works and its impact on your website's performance.

Download the POC from GITHUB


Abstract

In order to explain what HTTP 2.0 server push does, we have to understand the problems associated with its predecessor (HTTP 1.1). We will analyze the intricacies associated with loading assets from an HTTP server and how it affects the performance of websites.

In order for a browser to load a website, it needs to send an HTTP request to retrieve the initial HTML file and once the server sends it back, the browser analyzes the HTML and identifies the other resources (CSS, JS, Images) required to render the web page.

The image above illustrates the process used by HTTP 1.1 compliant server/clients to download all resources required by a website to render.

HTTP 1.1 Issues

Since the browser needs to parse the HTML file for it to fully identify all the assets it needs to completely render a web page, we can conclude that:

The initial HTTP request and parsing of the HTML file blocks the full download of relevant assets.

To make things worst, in order for a browser to send the initial HTTP request (for HTML file) it needs to perform the following tasks:

  • Resolve the DNS of the domain where the website is hosted. (1 Round-trip with DNS server)
  • Undergo a round trip between the web server and client machines to open a TCP socket. (Done for each asset)
  • Transfer is subjected to Payload Weight * Latency * Network Bandwidth factors.

What make things even worst is after the initial HTTP request completes, the browser would have to issue more HTTP request for the additional assets which depends on the dependency graph (Referenced JS, CSS, IMGs, HTMLs via iFrame) and behavior of the downloaded asset. These subsequent assets all have to undergo the same download process like how the initial HTML file was downloaded which results to exponential performance (Nn) deterioration.

Comparing HTTP 1.1 and 2.0 Asset Download Mechanisms

In order to clearly present the problems with the behavior of HTTP 1.1, I created a simple website showing the Eiffel tower's photo with three static JS and CSS files. We would be using this website to perform some observations on the differences between how HTTP 1.1 and 2.0 compliant parties transfer assets over the web.

I have checked-in an HTTP 1.1 and 2.0 version of the test website over a repository in Github. In order to replicate the test in your machine, you can clone or download the repository on your local machine and install the NPM dependencies on both folders.

Diagnosing HTTP 1.1 Issues

If you have successfully installed the NPM dependencies, please run the demo app using http-server on the HTTP 1.1 folder. Once the server is running, browse http://localhost:8080 on Google Chrome and open developer tools and navigate to the network tab.

Google Chrome's network waterfall diagram is used for diagnosing behavior associated with loading assets belonging to a web page. It presents a list the assets retrieved by the browser from web servers to render a web page. Each line in the diagram represents an asset retrieved by the browser. The waterfall bars on the right represents the time taken by the browser to download each asset.

Key Points

  • A longer bar in the diagram signals a longer download time.
  • The position of the bar (Left to Right) in the diagram represents its position in the asset download sequence (Subjected to sorting of the list).
  • The empty space from the left side of each waterfall bar represents the asset is in stalled (Pending) mode.

HTTP 1.1 Analysis

If you pay attention to the diagram, you would notice that there is a single green bar at the start of the diagram and all the remaining bars are plotted after a gap at the end of the first bar. The GAP between represents the time the remaining assets were stalled due to parsing of downloaded HTML file.

The scenario above happens because of the browser's failure to detect the dependencies until it parses the initial HTML and this is the exact problem why HTTP 2.0 server push was formulated.

PS: Please note that the diagram above does not reflect latency factor. The website is hosted on my machine and do expect an inferior performance on websites hosted on remote web servers.

HTTP 2 Server Push

In order to solve the browser's incapacity to quickly detect web page dependencies, HTTP 2.0 introduced the concept of Server Push. Server push is a mechanism that enables web servers to send browsers the list of assets they need to download to completely render a web page.

Testing HTTP 2.0

In order to present the advantages of HTTP 2.0, I will be utilizing Commons Host Server. It is used for hosting web pages on HTTP 2.0 and was built by Commons Host. If you want to perform an identical test on your machine, You can download or clone the source code from Github.

Pre-requisites

In order for you to run the code from the repository above, you would need the following:

  • NodeJS 10+ Installed
  • NPM
  • Google Chrome.

After downloading the HTTP 2.0 folder from the Github repository, you can use the following command to run the web server.

After running the script above on your terminal, navigate to https://localhost:4433. NOTE: HTTP 2.0 enforces accessing websites via HTTPS protocol.

Analyzing HTTP 2.0 Server Push

HTTP 2.0 waterfall diagram of the Paris website.

The waterfall diagram for the HTTP 2.0 web page reveals that the web page's dependencies were downloaded before the end of the initial HTML file's download time (You can read this from the diagram through the translucent blue bars). This signifies the elimination of the idle time wasted for downloading and parsing the initial HTML through HTTP 1.1.

What does the translucent blue bars mean?

The translucent bars in the waterfall diagram signifies the push receive time. This bars are present because the web server pre-emptively pushed the web assets (dependencies) together with the initial HTML file to the browser's cache storage.

How about the solid blue bars?

The solid blue bars represent the push read time. This bars represent the act of retrieval of the web assets stored in the cache of the browser. Since the dependencies are pushed pre-emptively, browsers don't have to open TCP connections to retrieve the asset from the remote server and don't have to wait for the download completion of the initial asset to complete before retrieving the remaining assets.

How did the magic happened?

Thanks to Commons Host, I was able to setup a manifest file that tells the server to pre-emptively push the dependencies of the index.html file on the web browser. You can read more on how to do it from Commons Host Gitlab Page.

Conclusion

HTTP 2.0 Server Push eliminates the time wasted by HTTP 1.1 clients on waiting and parsing of the initial HTML file to download all the web page's dependencies.

Please Support HTTP 2.0 Initiative

My friends and I are currently looking for developers that are willing to volunteer to help in the development of web servers that are capable of HTTP 2.0 server push. This initiative aims to eliminate the need to write manifest files and fully implement server push on protocol level. Anybody interested in helping our noble initiative can contribute in the following ways:

  • Help us write code!
  • Hosting a kick-ass POP server on your house!

Feel free to contact Sebastian Deckers to know how can you contribute to HTTP 2.0 server push initiative!


Why don't you become a web performance specialist?

Comments

Popular posts from this blog

Building Simple API Gateways with Ocelot and ASP.net Core

API Gateway: Response Aggregation with Ocelot and ASP.net Core

Replicating Netflix Part 1: Installing Raspbian Lite using Etcher

API Gateway in a Nutshell