HTTP/2 Push updates

Future changes for HTTP/2 Push support

In November 2020 came the news that Chrome is planning to drop support for HTTP/2 server push. Still Firefox and Safari both support HTTP/2 push and have not indicated any plans for removal. In this article we dive into the reason behind the Chromium Core Team decision.

Background

HTTP/2 allows servers to “push” a resource that the client will likely need before the client actually requests it, see HTTP/2 specification on Server push . Server push is meant as a performance optimization, and the specification allows the client to reject the pushed resource at its discretion.

gQUIC is a non-standard protocol supported by Google servers, Akamai, and Litespeed. It also allows servers to push resources in a fashion very similar to HTTP/2. gQUIC is being obsoleted by HTTP/3 and support will eventually be removed entirely. HTTP/3 is an almost-RFC protocol that also defines server push, see HTTP/3 draft on Server push.

Chrome currently supports handling push streams over HTTP/2 and gQUIC, and this intent is about removing support over both protocols. Chrome does not support push over HTTP/3 and adding support is not on the roadmap.

Motivation behind the decision

Almost five and a half years after the publication of the HTTP/2 RFC, server push is still extremely rarely used. Over the past 28 days, 99.95% of HTTP/2 connections created by Chrome never received a pushed stream (Net.SpdyStreamsPushedPerSession), and 99.97% of connections never received a pushed stream that got matched with a request (Net.SpdyStreamsPushedAndClaimedPerSession). These numbers are exactly the same as in June 2019. In June 2018, 99.96% of HTTP/2 connections never received a pushed stream. These numbers indicate the lack of active efforts by server operators to increase push usage. On top of this, less than 40% of received pushes are used, down from 63.51% two years ago. The rest are invalid, never get matched to a request, or already in cache.

Server push is very difficult to use well - and this we know at ShimmerCat (and that is why we use AI to handle it). Akamai publicly shared two studies showing that push over HTTP/2 either does not change performance or improves performance marginally when used with certain restrictions, see the H2 Server Push performance data. However, these studies had been done more than a year ago and push usage data still does not indicate wide deployment even within Akamai’s network. In light of this it is doubtful that smaller server operators have the resources to successfully deploy server push.

A contrasting result has been presented to the same IETF in 2018: a large experiment done by Chrome to measure the effect of server push on page load latency when using HTTP/2 showed that push increases latency at the long tail, see the presentation “Chrome’s view on Push”.

Looking forward

We have a feeling that there is a significant risk that HTTP/2 server push will be removed also in Firefox and Safari, if Chrome pushes ahead with the removal.

One major reason for this is that there is significant code complexity associated with supporting push: pushed requests have to be stored in an in-memory cache, looked up by URL across connections but only if the connection is authoritative for the request, matched by other parameters (method and other headers), and evicted after a timeout. Running associated tests burden developers and infrastructure when developing unrelated features, and users bear the burden of increased binary size. And these complexities seem to outweigh the theoretical performance benefits.

However, since this depreciation will not come instantly (and with this we probably mean a few years), and we can see that HTTP/2 server push definitely does have a positive impact on performance - especially for first-time visitors - we will continue to deliver our top-class implementation of the feature to our users until then.

Read more:

• Intent to Remove: HTTP/2 and gQUIC server push
• HTTP/2 Push is dead