Turboboost

Google and Microsoft

As early as the beginning of the 2010s, Google presented an alternative method for exchanging data between client and server with the SPDY protocol, which defined an increase in responsiveness and solved the limitation of the amount of data to be transferred. In addition to SPDY, Microsoft's development of HTTP Speed+Mobility also served as the basis for today's HTTP/2 protocol.

One major change from HTTP/1.1 is that it is a binary protocol, compared with the previous text-based protocol. Therefore, HTTP/2 can no longer be read or created manually. It also compresses the header. Because the header is similar for most requests, the new protocol combines them, preventing unnecessary duplicate transmission of data. Furthermore, HTTP/2 allows the server to send data in advance to the client cache before the client requests it. For example, assume an index.html file loads the style.css and script.js files within the data structure. If the browser connects to the server, the server first delivers the content of the HTML file. The browser analyzes the content and finds the two instructions in the code to reload the style.css and script.js files.

Only now can the browser request the files. With HTTP/2, it is possible for web developers to set rules so that the server takes the initiative and delivers the two files (style.css and script.js) directly with index.html, without waiting for the client to request them first. Therefore, the files are already in the browser cache when index.html is parsed, eliminating the wait time that requesting the files would otherwise entail. This mechanism is known as server push .

Server Push with Apache and Nginx

Because a server cannot know which files depend on what others, it is up to the web developers or administrators to set up these relationships manually. On Apache 2, the instruction can be stored in httpd.conf or .htaccess. For example, to push a CSS file whenever the browser requests an HTML file, the instruction for the httpd.conf or .htaccess file is:

<FilesMatch "\.html$">
  Header set Link "</css/styles.css>; rel=preload; as=style"
<FilesMatch>

To add multiple files, you can use add Link instead of set Link:

<FilesMatch "\.html$">
Header add Link "</css/styles.css>; rel=preload; as=style"
Header add Link "</js/scripts.js>; rel=preload; as=script"
</FilesMatch>

Here, you could also imitate pushing files from foreign sites by adding crossorigin to the tag:

<FilesMatch "\.html$">
Header set Link "<https://www.googletagservices.com/tag/js/gpt.js>; rel=preload;as=script; crossorigin"
</FilesMatch>

If you cannot or do not want to change the Apache files, you could still imitate pushing files with the header function of PHP or other server-side scripting languages:

header("Link: </css/styles.css>; rel=preload; as=style");

To push multiple resources, you separate each push directive with a comma:

header("Link: </css/styles.css>; rel=preload;as=style, </js/scripts.js>;rel=preload;as=script, </img/logo.png>;rel=preload; as=image");

You can also combine this directive with other rules included with the Link tag. For example, simultaneously issuing a push directive with a preconnect hint,

header("Link: </css/styles.css>; rel=preload; as=style,<https://fonts.gstatic.com>;rel=preconnect");

tells the server to push the style.css file to the client and simultaneously to establish a connection to fonts.gstatic.com. Because Nginx does not process .htaccess files or the like, the instruction can also be implemented, as described earlier, with PHP or directly in the server configuration by extending the location paragraph to include the http2_push command (Listing 5).

  location / {
   root /usr/share/nginx/html;
   index index.html index.htm;
   http2_push /style.css;
   http2_push /logo.png;
  }

Many Small Files vs. One Big File

Over the years, HTTP/1.1 has shown that HTTP pipelining places a heavy load on a server's resources. From a purely technical point of view, this means that the browser puts the requests for the required files into a pipeline, and the server processes them one by one (Figure 1). For web developers, this previously meant that their goal had to be to reload as few individual files as possible. Therefore, combining individual CSS or JavaScript files, for example, has proven to be very helpful. Loading a single 80KB CSS file is faster than loading eight 10KB files, because each request for a new file again takes time to establish the TCP connection.

Figure 1: Calling up a page with HTTP/1.1 makes it clear that the server delivers the files one by one and only as many files at the same time as there are processes free – usually five to eight.

Not all files can be combined and downloaded as a single file, especially for images, so HTTP/2 has become a multiplex protocol. One of the two core changes is that a client only opens one stream to the server over which all files can be transferred, without opening a new stream for each new request. The existing TCP connections are thus more durable, which in turn means they can achieve full data transfer speeds more often.

The second change is that this adaptation allows the server to send files in parallel rather than serially. Instead of one file at a time, the server now delivers many files at once (Figure 2). Conversely, the previously mentioned rule with the eight CSS files now no longer applies. On the contrary, applying this rule slows down the website unnecessarily, because the maximum transfer time for all files is the same as the transfer time for the largest file. For example, if transferring an 80KB file takes 347ms, transferring eight 10KB files takes only about 48ms, because the server delivers them at the same time. With HTTP/2, browsers typically use only one TCP connection to each host, instead of the up to six connections with HTTP/1.1.

Figure 2: If the server uses HTTP/2, you can see that it starts delivering a large number of files at the same time.