HTTP Preload and HTTP/2’s feature “Server Push” are both methods that can be used to improve the loading efficiency of your web application. Although there are similarities between Push and Preload, they are two distinct features and each serve their own purpose. In this article, we’ll go over the similarities and differences between HTTP Preload vs HTTP/2 Push and discuss when it makes sense to use each.
What Is HTTP/2 Push?
HTTP/2 Push allows web developers to define specific assets that should be pushed to the client along with the HTML document. Traditionally, the client requesting resources from the server initially receives the HTML file and parses it to determine which assets it needs to request next. Then, further requests are made to the server.
However, with HTTP/2 Push enabled, the server can proactively push assets that are known to be required before the client even begins parsing the HTML file. For example, if we have a website with an
index.html file and a
style.css file, the browser would traditionally first request the
index.html and once received/parsed, would then make another request for the
style.css file. However, since we know that the client is going to be requesting the style.css file anyway, we can tell the server to send the
style.css to the client at the same time it sends the
This makes for a more optimized asset delivery process. That being said, some may think, “Great! So I’ll just tell the server to push all of my assets to the client with the HTML file”. However, there are certain caveats to using HTTP/2 Push and over-using it can actually degrade performance.
What Is HTTP Preload?
HTTP Preload is another method web developers can use to proactively send certain assets to the client before requiring the client to request each asset sequentially. The Preload directive however works differently from HTTP/2 Push. With the Preload directive you can tell the browser to request certain high-priority assets, which are otherwise discovered late, once the HTML file has been parsed.
Consider the following example: a browser makes a request for
index.html. The browser receives the file and upon parsing it finds that it will need to request
style.css and within that css file a
font.ttf file is referenced. Instead of requesting
font.ttf sequentially, preload allows you to send a request to the server for both
font.ttf at the same time. Since
font.ttf is an asset that will be needed in the near future, preloading it would be an efficient way to request it.
Similarities vs Differences
HTTP Preload and HTTP/2 Push are similar in that they are both mechanisms that preemptively provide the browser with necessary assets before the browser knows that they are even required. However, there does exist a few important differences between Preload and Push. For instance:
The syntax various slightly between Preload and Push. You can use the Preload directive to initiate a push however this depends on the capabilities of your server/CDN. If you want to explicitly Preload an asset and not Push it you can use
Link: rel=preload; </app/script.js>; as=script; nopush
You can Push assets as soon as the server receives the initial request from the browser. However, you can only Preload once the browser has received and parsed the HTML file.
You can Preload assets from third party domains whereas you can only Push assets from your own domains.
The browser support for Preload isn’t perfect yet. Firefox, IE, and Edge are all browser that either don’t support or only partially support the Preload mechanism. Push however has more support as it is an HTTP/2 feature which is now the latest version of the HTTP protocol for the Internet. See the current browser support statistics for Preload here and for Push here.
Preload allows you to better define prioritization with the
asattribute whereas the responsibility of prioritization with Push is shared among the client and server.
To better explain the differences between Preload and Push, below is a simple diagram by Nginx which shows the difference between loading sequentially vs preloading vs pushing resources.
When to use Preload vs Push?
There are certain situations where Preload works better than Push and vice-versa. Neither preload or push should be used as a way to speed up the delivery of all your assets at once. Instead you should determine what your high-priority resources are and go from there.
Here are a couple of use cases for when to use Push:
- Push is also great for utilizing think time in a more efficient manner. As a server generates a website’s HTML file no further requests can be made by the browser as it must wait until the HTML file is received before knowing what to request next. However, depending on your server’s think time you can use it to your advantage by pushing necessary resources to the browser along with the HTML file, once generated.
Here are a couple of use cases for when to use Preload:
- Loading critical CSS that is discovered late
- Loading above-the-fold images referenced within a CSS file
- Loading fonts references within a CSS file
Using Preload and HTTP/2 Push with KeyCDN
Both Preload and Push make use of the Preload directive (as strange as that sounds). Therefore since KeyCDN supports HTTP/2 Push, if you set a
Link header with the Preload directive, KeyCDN will push that asset:
add_header Link "</style.css>; as=style; rel=preload";
However, as mentioned above, if you don’t want to push an asset, you can set the
nopush attribute. Additionally, if the HTTP/2 implementation doesn’t accept pushed assets, the client will consider this as a regular preloaded asset.
Properly pushing resources with KeyCDN can make a significant improving on your webpage’s loading time. To measure this we created a demo page and measured the difference in speed between a page with no pushed assets and the same page with 2 pushed assets. The difference resulted in a 12.5% decrease in time spent waiting. To learn more about how KeyCDN supports HTTP/2 push and the speed test we ran, check out our KeyCDN launches HTTP/2 push support post.
HTTP Preload and HTTP/2 Push are both useful mechanisms in their own regard. Although the difference and functionality between both still isn’t 100% clear to all servers/proxies, they do function in different ways. The key with using either is to implement a change and then test the difference in page speed. It’s easy to get carried away and try to Preload or Push everything although, as already mentioned, that can do more harm then good. Take it slow and experiment with Preload and Push in your own application.
Source: Web Dev