KeyCDN Launches HTTP/2 Push Support

The ability to push assets to a browser before it even knows that it needs them was one of the abilities that HTTP/2 introduced. This is known as HTTP/2 Server Push, which can be quite useful in minimizing the number of round trips, and thus overall wait time, incurred by a visitor. Today, we're excited to announce that KeyCDN now supports HTTP/2 Push.

This will allow users to configure their origin server in a way that defines which assets should be pushed along with the initial HTML document. KeyCDN will then honor the HTTP/2 Push assets defined within HTTP headers and subsequently cache the responses for even greater savings. Read on to learn more about HTTP/2 and how it works with KeyCDN.

What is HTTP/2 Push?

A typical website is designed so that the first file a browser will request is the HTML file. Within the HTML file are links to other files needed to load the content within the HTML. Therefore, traditionally one round trip is made to request the HTML file and once the browser knows what other files it requires to load the page, it makes additional requests for those files.

This process, however, creates additional round trips which is what HTTP/2 Push aims to minimize. With HTTP/2 Push, developers can define certain files to be pushed to the browser at the same time as the initial HTML document. So let's say style.css and script.js are both required to load the content of index.html. Once a browser makes a request for index.html, the server will automatically respond with index.html, style.css and script.js.

This is relatively simple and can provide a nice performance boost as we'll show below. However, there are also certain caveats to using HTTP/2 which are also highlighted in a further section. Knowing when to use HTTP/2 and not "overusing it" is vital to ensuring you benefit from the savings HTTP/2 Push can provide.

How to use HTTP/2 Push with KeyCDN

There are no special requirements that need to be configured within the KeyCDN dashboard in order to enable HTTP/2 Push support. However, HTTP headers do need to be defined on the origin server side which specify which resources are to be pushed upon the initial request of a website's HTML file.

Assets are pushed using the Link header and usually take on a format similar to the following:

link:</push.css>; as=style; rel=preload

In the example above, link is the HTTP header, /push.css is the file being pushed, as=style informs the browser of the asset's content type and rel=preload is, in most cases, interpreted by HTTP/2 implementations as a way to push the asset. If the HTTP/2 implementation doesn't accept pushed assets, the client will consider this as a regular preloaded asset.

As an Nginx user, you can define all Link HTTP headers within your configuration file. An example of this for the file above would look like:

add_header Link "</style.css>; as=style; rel=preload";

As an Apache user, you can either define the HTTP headers within your .htaccess file or configuration file. An example of what this would look like is:

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

HTTP/2 Push speed comparison

To show the difference in speed between using HTTP/2 Push and using HTTP/2 Push with KeyCDN, we ran a simple test. This test included an HTML file which linked to two CSS files (one pushed and one not pushed) as well as one pushed image. The HTML file's response headers for this test were as so:

Loading the files via Chrome from the origin without KeyCDN enabled produced the following results:

Overall load time was just 73 ms with the PNG image being the asset taking the longest amount of time (56 ms). Now, let's take a look at what the results were with an HTTP/2 Push-enabled server, accelerated by KeyCDN.

The overall load time, in this case, was just 62 ms, resulting in a 12.5% decrease in time spent waiting. As the pushed assets are already cached in the nearest KeyCDN edge server, those files are delivered immediately and less latency is incurred thanks to the CDN server being closer to the visitor than the origin.

Now of course, you may find it tempting to push more and more of your assets to even further decrease load times. However, this isn't always a good idea. In fact, doing this for too many assets can actually hurt performance more than help it. We'll discuss this topic further in the HTTP/2 Push Caveats section below.

HTTP/2 Push vs Preload

The preload directive is somewhat similar to HTTP/2 Push and perhaps you're unsure as to what the differences and similarities are between the two. Afterall, rel=preload is used in the examples above to initiate a push.

As mentioned above, the preload directive is interpreted by certain HTTP/2 Push implementations as a way to actually push assets instead of preload them. However, there is a difference between both ways of loading content in advance.

HTTP/2 Push allows you to push assets to the browser before it has even had a chance to parse the HTML file. This saves time as usually, the network is idle when the server needs to generate the HTML file. Therefore, if assets which are known to be required are pushed during that idle time, content loading can happen more efficiently.

Preload, on the other hand, is great for resources discovered late in the loading process by the browser. However, preload does not allow you to push assets to the browser before receiving the HTML file. Instead, preloaded assets can only be initiated after the browser receives the HTML file, parses, and finds the preload tags.

Below is a simple diagram by Nginx which shows the difference between loading sequentially, vs preloading vs pushing resources.

HTTP/2 Push caveats

Although there are obviously some performance benefits to be had through using HTTP/2, there are also some caveats to be aware of. Jake Archibald has written an in-depth post about this, however, we'll summarize a few important points what should be taken into consideration before deciding whether or not to implement HTTP/2 Push for your own use-case.

• Pushing too much stuff can actually hurt performance. With a large number of assets, or assets that are large in size all being pushed to the browser at once, delays may be incurred in terms of how soon your page will be interactive. It's better to start small and perform your own tests when adding other assets to push.
• Push cache is lost if the connection closes. Therefore, push is best used for urgent resources required to display the page quickly.
• Browsers can decline pushed items if they already have them in their cache. This can cause wasted bandwidth as the browser won't know that it has the pushed asset in cache until it has received it.
• Preloading is easier to debug and simpler than Push although will be slightly slower in most cases.

Should you use HTTP/2 Push?

HTTP/2 Push is a powerful feature that can provide some significant performance improvements thanks to the reduced number of round trips required. However, as mentioned above, there are certain caveats to using HTTP/2 Push.

It's not the answer to all performance issues and should not be over-used. However, If you're comfortable with making server side adjustments and performing tests on your web application to determine which high-priority assets should be pushed, consider giving HTTP/2 Push a try. Moreover, use KeyCDN and even further accelerate the delivery of those assets with the help of our global network of edge servers.