It is extremely annoying that all of this sudden discovery that http2 push didn't work hasn't come with some kind of apology to everyone out here who had tried to explain before why this wouldn't work and why it would be a dangerous waste of time just to be shouted down for years by the people insisting it was going to be epic as the much-smarter people at Google knew what they were doing and really needed this so we should just let them ram it into the spec. We should be extremely conservative about what we put in the spec and stop just throwing in speculative stretch goals because some people at Google thought it's a good idea.

I never found the explanations given for why HTTP/2 Push failed compelling. Google usually just refers to a blog post from Jake Archibald [1], but that post seems to call out all the ways browsers poorly implemented it rather than reasons the protocol itself wouldn't work.

Browsers already support preload links, which should function effectively the same as a Push header. Why couldn't that same code have been used for Push, including all the existing handling for things like caching and authorization headers that Jake called out as challenges with the 2017 implementations?

[1] https://jakearchibald.com/2017/h2-push-tougher-than-i-though...

You can get some of this speed back with HTTP/3 0-RTT start, and use 103 Early Hints to make browsers preload assets early. This combo has an advantage of being semantically backwards-compatible with HTTP/1 (reverse proxies, load balancers).

I'm a bit sad to finally see the death of HTTP/2 Push. It was a neat idea, with poor framework uptake that never really got the attention I think it could've benefitted from. The .NET folks never bothered shipping it; there was a basic implementation in nginx. It was always hamstrung by lack of cache digests too. Chrome ultimately got rid of it with a justification partially along the lines of "nobody would notice anyway" and because re-architecting everything to use UDP (because that works great with NAT, doesn't it?) was apparently more important.

Remember talking to Mike Belshe (SPDY, and H2 spec co-author) before H2 was standardised and even then they were trying to get it dropped from H2 as the benefits were hard to realise, there were plenty of issues and foot guns too

One of the largest issues was 'over-pushing' through either sending something that was already in the browser cache, or just trying to push way too much non-critical content (I've seen some truly bad cases of push actually making the page slower to load)

There were some proposals to allow the browser to communicate to the server what was already in the local cache but these ran into some issue

HTTP Early Hints and Resource Hints have largely removed the need for H2 Push in a way that's much easier to implement, avoids unnecessary fetches and it's easier to reason about too

> This means that if webservers and websites use push and don't test in Firefox, this feature can potentially cause websites to stop working only in Firefox

That is one reading of the situation.

The other would be:

All other browsers reject HTTP/2 Push & gracefully ignore it, but Firefox majorly trips up in edge cases.

(quote: «It seems that Firefox is resetting the connection because it encounters an uppercase character in the header names»).

Why wasn't push adopted more widely? It was one of the big reasons HTTP2 was meant to be a game changer (despite the massive flaws)

Was it a lack of browser support? or that it didn't really work with CDNs?

… in Firefox.

Related (I think). Others?

Removing HTTP/2 Server Push from Chrome - https://news.ycombinator.com/item?id=32522926 - Aug 2022 (201 comments)

A Study of HTTP/2’s Server Push Performance Potential - https://news.ycombinator.com/item?id=32097013 - July 2022 (2 comments)

HTTP/2 Push is dead - https://news.ycombinator.com/item?id=25283971 - Dec 2020 (168 comments)

Blink: Intent to Remove: HTTP/2 and gQUIC server push - https://news.ycombinator.com/item?id=25064855 - Nov 2020 (133 comments)

We're considering removing HTTP/2 Server Push support - https://news.ycombinator.com/item?id=24591815 - Sept 2020 (2 comments)

Performance Testing HTTP/1.1 vs. HTTP/2 vs. HTTP/2 and Server Push for REST APIs - https://news.ycombinator.com/item?id=21937799 - Jan 2020 (71 comments)

How HTTP/2 Pushes the Web - https://news.ycombinator.com/item?id=18216495 - Oct 2018 (16 comments)

Nginx HTTP/2 server push support - https://news.ycombinator.com/item?id=16365413 - Feb 2018 (63 comments)

HTTP/2 Server Push on Netlify - https://news.ycombinator.com/item?id=14798271 - July 2017 (23 comments)

The browser bugs and edge cases of HTTP/2 push - https://news.ycombinator.com/item?id=14445728 - May 2017 (20 comments)

A Guide to HTTP/2 Server Push - https://news.ycombinator.com/item?id=14077955 - April 2017 (59 comments)

HTTP/2 Server Push - https://news.ycombinator.com/item?id=13990074 - March 2017 (2 comments)

HTTP/2 Server Push and ASP.NET MVC – Cache Digest - https://news.ycombinator.com/item?id=13659962 - Feb 2017 (9 comments)

Accelerating Node.js Applications with HTTP/2 Server Push - https://news.ycombinator.com/item?id=12296922 - Aug 2016 (6 comments)

Rules of Thumb for HTTP/2 Push - https://news.ycombinator.com/item?id=12224258 - Aug 2016 (25 comments)

Google's Rules of Thumb for HTTP/2 Push - https://news.ycombinator.com/item?id=12223352 - Aug 2016 (2 comments)

HTTP/2 Protocol for iOS Push Notifications - https://news.ycombinator.com/item?id=11175980 - Feb 2016 (13 comments)

Well I'm not surprised. This is usually what happens when you take an existing protocol meant for a specific purpose and try to tack on additional functionality on top which has little to do with the original design goals of the protocol; you're almost always better off starting out with a low level protocol and going straight for your use case. In that respect, I think WebSockets already solved the problem of bidirectional communication elegantly.

In terms of reducing latency when loading deep file/script hierarchies, the <link> tag with rel="preload" or rel="modulepreload" is an excellent, simple construct.

I was just thinking about it yesterday! It would be a nice way to implement REST APIs for related resources.

For example, if we have a /books collection with related authors for each book, client could request books with authors. Server would then fetch the books and authors in a single DB request, return just the books, and push each author as an additional response.

Of course, this can be implemented with other mechanisms (JSON:API [0] comes to mind), but this seemed like a nice idea to explore. Guess we’ll never know!

[0]: https://jsonapi.org/

[dead]

[flagged]

HTTP/2 Push was really useful when we wanted to avoid Websocket , Ajax Polling , Long Polling.

The problem with not adopting is due to Websocket getting more popular and Devs stop caring about HTTP2 altogether. But there are many cases Websocket is overkill , even text chat application dosen't need websocket.

Similar functionality can already be achieved by using SSE/Eventsource although HTTP/2 Push was more powerful.