HTTP/2 Server Push

HTTP/2 Server Push is an optional feature of the HTTP/2 and HTTP/3 network protocols that allows servers to send resources to a client before the client requests them. Server Push is a performance technique aimed at reducing latency by sending resources to a client preemptively before it knows they will be needed. In practice, Server Push frequently results in wasted bandwidth because the server rarely knows which resources are already loaded by the client and transmits the same resource multiple times, resulting in slowdowns if the resources being pushed compete for bandwidth with resources that were requested.

HTTP/2 Server Push is not a notification mechanism from server to client. Instead, pushed resources are used by the client when it may have otherwise produced a request to get the resource anyway.

History
On May 14, 2015, HTTP/2 was standardized by, ratified as a Proposed Standard. The document includes section 8.2 entitled "Server Push" which introduced the concept to the protocol as an optional extension. Google Chrome 40 became the first browser supporting the final standardized HTTP/2 version, including the optional Server Push.

In February 2018, Nginx 1.13.9 was released with optional support for HTTP/2 Server Push.

In November 2020, Google announced its intent to remove Server Push from Google Chrome implementation of HTTP/2 and gQUIC (which later evolved into HTTP/3).

In October 2022, Google announced their intent to remove Server Push from Google Chrome citing the poor performance of the extension in practice, lack of use and better alternatives. Chrome 106 became the first release disabling Server Push by default.

Protocol
Unlike HTTP/1.1, HTTP/2 can multiplex multiple streams on one TCP connection. Server Push allows the server to open new streams by sending PUSH_PROMISE frames, in order to send the client resources it expects will be needed. A PUSH_PROMISE frame is similar to a GET request, but sent by the server. A client may choose to reject the push by sending an RST_STREAM frame, for example if it already has the resource cached; if it does not, it will store the pushed data in a cache associated with the connection which will be consulted before a request is sent down that connection. Clients can also request that servers not send server pushes using a SETTINGS frame. The specification itself does not specify how servers choose what to push: a webserver might send pushes to clients only on their first visit, to avoid redundantly sending cached resources.