Summary

  • RFC 7540 gave HTTP/2 servers a way to send likely follow-up resources using PUSH_PROMISE. A browser could disable or reject the offer; a server's prediction was never a request from the client.
  • RFC 9113 retained Server Push in June 2022 and described how cache state, content negotiation and user behavior could make the prediction expensive. Chrome 106 removed the ability to receive, hold and use pushed HTTP/2 streams later that year.

A server volunteers to answer first

Imagine a browser requesting a page. The server knows that the page refers to a stylesheet. Instead of waiting for the browser to read the HTML and ask for the stylesheet, the server sends a promise to provide it, followed by the resource itself. One round trip might disappear. That was the proposition in HTTP/2's May 2015 specification. It was an attractive piece of scheduling: move work earlier, fill time that would otherwise be spent waiting.

The wire mechanism made the distinction between promise and request precise. A PUSH_PROMISE frame announced a request that the server had synthesized on the client's behalf. The response then traveled on a separate stream. The server could do this only in connection with a request the client had actually initiated. Safe, cacheable requests and authority checks constrained what could be pushed. A client could set SETTINGS_ENABLE_PUSH to zero, refuse a promised stream, or reset one it no longer wanted. The standard permitted the server to speculate; it did not force the browser to accept the parcel.

That permission looked especially useful when web pages assembled many files. A server can see the HTML it is about to send and may know which script or stylesheet follows. But the server does not see everything the browser knows. The browser might already have the file in its cache. A different variant might be needed. The user might leave before the resource matters. Sending bytes early consumes the same connection capacity that an actual, urgent response needs.

The revision kept the feature and named the trap

The IETF's June 2022 HTTP/2 revision, RFC 9113, still devoted a full section to Server Push. It restated the hoped-for saving: if the server predicts a later stylesheet or script request, the browser may avoid waiting for the HTML reference and making another request. The same section described the operational difficulty in unusually plain language. Correct prediction must account for caching, content negotiation and user behavior. A wrong prediction can slow the page by putting unwanted data ahead of more important responses.

The revision also kept the refusal mechanism. A browser could tell the server not to push with SETTINGS_ENABLE_PUSH=0; the server then had to honor that setting. This is one reason the feature's appearance in an RFC cannot establish that it is working on a reader's screen. The document defines a permitted exchange and the conditions for refusing it. Product teams decide whether their browser will spend memory, bandwidth and engineering effort on that exchange.

In August 2022, Chrome said it would disable HTTP/2 Server Push by default in Chrome 106. It cited difficulty obtaining reliable performance gains and mixed results, including regressions. Its Chrome 106 removal notice used narrower operational language: Chrome removed the ability to receive, keep in memory and use pushed streams from the server. The standard's Server Push section remained on the books. Chrome stopped doing the receiving work.

The sequence is the heart of the story. In 2015, the protocol gave servers a head start. In June 2022, its revision still allowed that head start while spelling out the costs of a bad guess. A few months later, Chrome closed its own receiving path. The feature had not been defeated by a sentence in a standards meeting. It lost a place in a working browser.

The parcel never gets a free ride

Chrome's removal explanation pointed to 103 Early Hints and preloading as alternative ways to start useful work sooner. Early Hints sends a clue; the browser decides whether to request the resource, including whether it already has a cached copy. That alternative appears here as Chrome's account of the replacement path. The historical event is the removal of the pushed response itself: the server may still know what it wants to send, but Chrome no longer accepts that unsolicited stream as a useful shortcut.

Server Push exposes an awkward fact about Internet standards. A written permission does not supply the browser's cache knowledge, guarantee a faster page, or pay for an implementation's continuing upkeep. The most elegant shortcut can turn into a parcel nobody asked for. HTTP/2 kept the rule; Chrome shut the receiving hatch.