Akamai Diversity
Home > Web Performance > HTTP/2 Server Push: The What, How and Why

HTTP/2 Server Push: The What, How and Why

What is HTTP/2 Server Push? How does it work? Why is it valuable? If you are looking for the answers to these questions, you've come to the right place.

 

Thumbnail image for http2_Server-Push.png

What it is

HTTP/2 (h2) Server Push is one of the performance features included in version 2 of the HTTP protocol.  It allows the Web server to "push" content to the client ahead of time (before the client requests it) as long as all the URLs are delivered over the same hostname and protocol.

HTTP/2 Server Push is based on the client's good faith of accepting a promise sent by a server for an object the client is going to need soon.

How it Works

HTTP/2 Server Push works like this: the server first announces the promise to the client which is pretty much the same as an HTTP response (consisting of a response headers and a response body) as if the client had made a request for that object to the server. The only difference from a "normal" response is the server is sending a set of generic temporary HTTP response headers, which probably won't include any personalized information like session cookies. The server sends the HTTP response headers and the bytes that make the object as long as the client does not sends a signal (RST_STREAM) to indicate rejection.

In most cases the client will accept a h2 promise, but there are some instances when it may reject the promised object, like when the client is busy or if it already has the promised object in its cache.

Let's see how server push works with an example. A web browser requests a webpage (index.html in our example), and the server returns to the client three objects: index.html, and two extra objects: scripts.js and styles.css (PROMISES of resources the client is going to need soon), which are stored on a special cache reserved for that purpose. The client then parses index.html and realizes it needs three objects to load the page: scripts.js, styles.css and image.jpg. The first two are already in the browser cache as they have been pushed by the server, so the client just needs to request image.jpg to the server in order to render the page.

The picture below shows this workflow over a timeline (orange boxes depict client requests, and blue boxes depict server responses).

Thumbnail image for h2-push-example.png

So far there are two main approaches for implementing server push today:

  • Hinted Push: Allows developers to "hint" which resources should be pushed to clients by using the "link rel="preload" HTML element either within the HTML, or via HTTP response headers. In the HTTP/1.1 world, preload is used to hint the browser's rendering engine to load an object that is going to be needed early to render the current page, but it may be discovered late by the renderer. In h2, this tag is repurposed as a hint from the Web server regarding which resources can be pushed to the client . For example to push a file called "/scripts.js" we would include the following: "Link: </scripts.js>; rel=preload; as=script." The benefit of this approach is it provides full control to web developers of what is pushed to clients. The drawback of this approach is the pushed objects may compete for bandwidth with the HTML.

  • Rule-based Proxy push: Allows a "smart" reverse proxy to automatically push objects to clients without having to wait to receive h2 hints from the origin server by means of a local manifest file containing list of objects to push for specific URLs. For example, a client requests index.html to a reverse proxy, the proxy request the HTML from an origin server and while it waits for the network to receive the HTML, it uses server push to send specific objects to the end user that are stored in the proxy's local cache. This approach of server push promises higher performance gains than hinted push because it allows to push content to the end user much earlier (giving a significant performance boost if the proxy's latency to the origin is high, or if the origin is slow to respond like for example in the case of a DB lookup).

Why it's Valuable...with a catch

Server Push promises performance gains as it allows sending bytes to clients when otherwise the network will be idling, however it can negatively impact performance if not done correctly. Here are some examples of how using Server Push could negatively impact the page load time:

  • Pushing resources that are already present in the browser's cache can waste precious bandwidth. This should be addressed with an upcoming standard called Cache Digests. In the meanwhile, developers can elect to push on first visit only or use cache-digest).

  • Having push resources compete with the delivery of the HTML, which can impact page load times. This can be avoided by limiting the amount and size of what is pushed.

That covers the what, how, and why for HTTP/2 Server Push. For a more details on HTTP/2 and server push, please check out the book "Learning HTTP/2."

Additional reading:

1 Comment

Estupendo artículo Javier. Yo tengo un problema desde la introducción del HTTP/2 y son error 408 y no damos con ellos ¿se te ocurre el porque pueden ocurrir? Gracias.

Leave a comment