WebPerf Rules of Thumb for HTTP/2 push Google Doc

eva2000 · Aug 10, 2016

Google folks published a Google doc in net-dev group a last week titled Rules of Thumb for HTTP/2 push.

Hi all,

Our team has been experimenting with H2 server push at Google for a few months. At first, we thought this would be pretty easy -- just push a few important resources, then boom! Pages load faster! Well, no. Sometimes pages did load faster. Other times they didn't. Other times pages were actually slower. Worse, we had trouble explaining why we saw those results. We eventually decided to scrap our initial experiments and ask more basic questions: How should one go about using H2 push? What are the best practices? We tried to distill our experiences into five "rules of thumb" that are described in this doc:
Rules of Thumb for HTTP/2 Push - Google Docs

The doc is a little long, but the first two pages give a decent tl;dr. The basic ideas are straightforward and perhaps "obvious" in retrospect, but it takes a surprising amount of careful reasoning to understand why your page is or isn't seeing better performance with H2 push. Hopefully other folks interested in H2 server push will find this useful.
-Tom, Simon, and Michael
Click to expand...

Rules of Thumb for HTTP/2 push Google Doc excerpt

Rules of Thumb for HTTP/2 Push
Tom Bergan, Simon Pelchat, Michael Buettner
{tombergan, spelchat, buettner}@chromium.org
Last Updated: 2016/08/03

HTTP/2 has a new feature called server push that promises to improve page load times. The idea: rather than waiting for the client to send a request, the server preemptively pushes a resource that it predicts the client will request soon afterwards. For example, if the server sends the client an HTML document, the server can reasonably predict that the client will also request subresources linked from that HTML document, such as JS and CSS files.

More broadly, we can build a fetch dependency graph for a page. This graph has an edge from A to B if resource A reveals the need to fetch resource B. For example, given that doc.html imports a.js and a.js import b.js via document.write, there is an edge from doc.html -> a.js and another edge from a.js -> b.js. Each time a client requests a.js, the server can proactively push b.js along with any or all of the other descendants of a.js in the fetch dependency graph.

Unfortunately, server push does not always improve page load performance. It is not always obvious why this is so. Further, indiscriminate use of server push can actually make page load times worse. This document compiles lessons we learned while experimenting with server push. Many of these lessons will be obvious and common-sense, at least in retrospect; others may not be so obvious.

To summarize, we recommend the following:

Push just enough resources to fill idle network time, and no more.
Server push eliminates idle network time between the server sending one response to the client and waiting for the next request. During this idle time, the server can fill the network with as many bytes as are allowed by the current TCP congestion window (cwnd). Pushing more than cwnd bytes has no additional benefit and can actually hurt performance, for reasons described below. A corollary is that TCP slow start makes server push less effective on cold connections than on warm connections.

Push resources in evaluation-dependence order.
The browser evaluates each subresource in a specific order. Pushing resources in the wrong order delays evaluation, which can delay discovery of hidden resources that are requested dynamically, which can make page load time worse. For this reason, it may be better to avoid pushing resources when their evaluation order is not precisely known, especially when those resources cumulatively exceed the current cwnd (recall rule #1).

Consider using special strategies to track the client-side cache.
Push wastes bandwidth when the client has already cached the resource being pushed. Further, pushing more than cwnd bytes makes page load time worse if the extra bytes pushed are already cached (again, recall rule #1). Unfortunately, there is no perfect, well-tested method to avoid pushing cached resources. We mention a few recent proposals.

Use the right cookies when pushing resources that vary by cookie.
Unlike the above issues, this is a correctness problem, not a performance problem. This is particularly important when a pushed resource depends on path-scoped cookies that may not have been sent with the mainframe request that initiated the push.

Use server push to fill the initial cwnd and consider using preload links to reveal the remaining critical or hidden resources.

In cases where a resource should not be pushed due to the above rules, a preload link may make more sense. Preload links cannot eliminate idle network time as well as server push. However, preload links are cache- and cookie-aware, and further, they can be applied to cross-domain or third-party resources, while a server can only push resources for which it is authoritative.
Click to expand...

Log in / Register

Forums

Want to subscribe to topics you're interested in?

WebPerf Rules of Thumb for HTTP/2 push Google Doc

eva2000 Administrator Staff Member

.

Log in / Register

Useful Searches

Want to subscribe to topics you're interested in?

WebPerf Rules of Thumb for HTTP/2 push Google Doc

eva2000 Administrator Staff Member

.