5 ms·

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 su

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?

swiftcoder 2y ago
You might like the more detailed breakdown published when Chrome decided not to support push: https://developer.chrome.com/blog/removing-push/ https://developer.chrome.com/blog/removing-push/
- Aachen 2y ago
  All that says (that is relevant to the posed question) is: > it was problematic as Jake Archibald wrote about previously, and the performance benefits were often difficult to realize Edit: Clicking through to the linked post by Jake, <https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/ https://jakearchibald.com/2017/h2-push-tougher-than-i-though...>, problems mentioned are - browsers had buggy implementations which wouldn't (always) use the pushed data. In that case, you've (as a web server) kept the connection busy and sent bytes for nothing - browsers ignore max-age when using push cache. Given that the time between pushing and using is usually <1 second, that seems fine to me? Don't get this one. Further down is another caching header caveat. Just don't push data to the cache that you don't want it to cache? - pushed data is dropped when the connection closes. Seems like a simple fix to me: keep data around until you navigate away from the page or the tab gets unloaded for any other reason. Or keep the connection open while the page renders because there might be more requests anyway, like for an image or commenter's avatar - different pages using the same connection can use each other's cache, so if you "open in a new tab" two links and one of them already pushed the /css/main.css then the other doesn't need to anymore. This sounds like a very useful feature, not a reason to remove push at all. Further down in the article, under a separate point, it says "Once the browser uses something in the push cache, it's removed", which sounds like this mechanism can't work at all and they'll steal each other's resources instead?! Surely that's not the case, since it makes the sharing entirely useless? - if you use authentication, make sure to send it along when requesting e.g. a font via JavaScript because otherwise it can't use the cache because you're not the same user. Okay, sounds reasonable and like a simple thing to do - not all browsers implemented cross-origin pushing Finally, there's a concluding paragraph starting with > There are some pretty gnarly bugs around HTTP/2 push right now, but once those are fixed I think it becomes ideal for the kinds of assets we currently inline, especially render-critical CSS. This doesn't sound like a reason to remove push altogether. Quite the opposite?
  - bawolff 2y ago
    Well there is a link with more info about what Jake wrote. The tl;dr: its hard to predict ahead of time what resources browsers really need, so often you send the wrong thing or the non ideal thing. End result is the practical performance benefit was much smaller than the theoretical one.
    - Aachen 2y ago
      I was indeed reading that while taking notes. The comment is now updated with those. I didn't read in the post what you said its tldr is supposed to be; maybe I read over it
    - kijin 2y ago
      The practical benefit is virtually nil because HTTP already has a proven mechanism for caching and preloading. By the time you visit the second page on a multi-page site, you are likely to have almost all stylesheets, scripts, and common images already cached. This means you will reject almost all of the resource the server tries to push to you. Even on the first page, modern browsers are very quick to identify resources they need to load, both from headers and the early parts of the document. They load those resources concurrently while they are still parsing the document, so they are rarely blocked for a noticeable time. Meanwhile, single-page sites have evolved to a point where the entire application is contained in one or two heavily optimized, minified scripts. You just load that one script and you're done. Most small images these days are SVG embedded right in the source code, so again, there's little need to push other resources. The only time a modern website makes you to load a lot of unanticipated resources is when those resources are used for tracking and advertising. They can't be pushed because they live on different origins.
      - acdha 2y ago
        > Meanwhile, single-page sites have evolved to a point where the entire application is contained in one or two heavily optimized, minified scripts. You just load that one script and you're done. Most small images these days are SVG embedded right in the source code, so again, there's little need to push other resources. This isn’t true of most websites - look at the developer tools traces - because it’s terrible for performance to optimize for the IE6-era browser design. With those kind of bundles, you have to push a ton of content which didn’t change any time one byte of any resource changes. Since HTTP/2 substantially reduced the cost of multiple requests any site which has repeat visitors will benefit enormously from letting the bulk of the content which hadn’t changed be cached and only refetching the few responses which actually need to be updated.
mhitza 2y ago
> Why wasn't push adopted more widely? It wasn't given enough time, would be my guess. First Apache release that included HTTP2 support was in late 2015, same year HTTP2 RFC finished going through the process. In 2017 there still was browser inconsistency on how server push was handled (one of the reference articles in the sibling comment link). nginx implemented support for push somewhere around 2018 (based on wikipedia information). All those changes need to trickle down. Versions available in stable distros, config defaults etc. First time I've enabled http2 on my Apache servers, was in 2020 (and there are likely application servers out there that still don't support it directly in 2024).
znpy 2y ago
> It was one of the big reasons HTTP2 was meant to be a game changer Probably because it's a game changer only if you're at google/amazon/meta (or slightly smaller) scale. For everybody else its largely a huge complexity addition, and it's essentially ignored.
- bawolff 2y ago
  I suspect the issue is it wasn't really a game changer at google scale either.
  - znpy 2y ago
    Yeah i kinda don’t trust google anymore on going good engineering work. Nowadays they look like the cushy job providers, like banks in the 80s (i guess)
- KaiserPro 2y ago
  We enabled HTTP2 in 2015 on the $big_financial_news_site. We had some influential JS people that were very keen to roll it out (they mostly ended up fastly after). I did warn that it would degrade all but the high bandwidth experience. It took a long time for them to "understand" the data, and that HTTP2 was not very useful, especially when compared the impact of changing CDN, or optimising for CDN caching.
JackSlateur 2y ago
Server push was never massively deployed because they may be harmful : the server pushes assets that may be needed by the client, but also may be already cached by the client. In the later case, this is a harmful burden, especially on mobile etc. The server is never able to truly know if the asset is actually required by the client Early hint is better, probably: the server quickly tells the client it will need those assets. The client can then decide if they must be fetched, or if they are already available.
alex_duf 2y ago
I looked into using this, but changed my mind. Say you get a hit on Index.html. you probably want to push script.js and style.css. So now you've pushed a few hundred kbits. Now, the user comes back and asks for index.html again: do you send everything again? Surely the resources are still in the user's cache. If you don't, how do you know what to send? Only the user's browser knows what's in can't and what's not. So you face the choice: speed up first visits but waste bandwidth for subsequent visits, out slow down first visits but speed up subsequent visits.
liveoneggs 2y ago
Can you explain the problem is solved better than Link headers, websockets, or SSE?
- SahAssar 2y ago
  Websockets and SSE are completely unrelated. Link headers can be used for preload, but until 103 Early Hints it could not be sent before the body content was processed on the server (unless your body content did not affect your headers, which is quite rare).
WhyNotHugo 2y ago
It’s really hard to architect around http push. Say I have a website in Python/Django, where I know that a page uses certain images. In order to use http push, my app would need to stream those images itself, rather than let a CDN or even Nginx do it. I suppose that some solution could have been implemented so that my Python app can tell nginx to stream certain static resources over a given connection… but the tools for that never surfaced. Most HTTP frameworks don’t support push.

swiftcoder 2y ago

You might like the more detailed breakdown published when Chrome decided not to support push: https://developer.chrome.com/blog/removing-push/ https://developer.chrome.com/blog/removing-push/

Aachen 2y ago
All that says (that is relevant to the posed question) is: > it was problematic as Jake Archibald wrote about previously, and the performance benefits were often difficult to realize Edit: Clicking through to the linked post by Jake, <https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/ https://jakearchibald.com/2017/h2-push-tougher-than-i-though...>, problems mentioned are - browsers had buggy implementations which wouldn't (always) use the pushed data. In that case, you've (as a web server) kept the connection busy and sent bytes for nothing - browsers ignore max-age when using push cache. Given that the time between pushing and using is usually <1 second, that seems fine to me? Don't get this one. Further down is another caching header caveat. Just don't push data to the cache that you don't want it to cache? - pushed data is dropped when the connection closes. Seems like a simple fix to me: keep data around until you navigate away from the page or the tab gets unloaded for any other reason. Or keep the connection open while the page renders because there might be more requests anyway, like for an image or commenter's avatar - different pages using the same connection can use each other's cache, so if you "open in a new tab" two links and one of them already pushed the /css/main.css then the other doesn't need to anymore. This sounds like a very useful feature, not a reason to remove push at all. Further down in the article, under a separate point, it says "Once the browser uses something in the push cache, it's removed", which sounds like this mechanism can't work at all and they'll steal each other's resources instead?! Surely that's not the case, since it makes the sharing entirely useless? - if you use authentication, make sure to send it along when requesting e.g. a font via JavaScript because otherwise it can't use the cache because you're not the same user. Okay, sounds reasonable and like a simple thing to do - not all browsers implemented cross-origin pushing Finally, there's a concluding paragraph starting with > There are some pretty gnarly bugs around HTTP/2 push right now, but once those are fixed I think it becomes ideal for the kinds of assets we currently inline, especially render-critical CSS. This doesn't sound like a reason to remove push altogether. Quite the opposite?
- bawolff 2y ago
  Well there is a link with more info about what Jake wrote. The tl;dr: its hard to predict ahead of time what resources browsers really need, so often you send the wrong thing or the non ideal thing. End result is the practical performance benefit was much smaller than the theoretical one.
  - Aachen 2y ago
    I was indeed reading that while taking notes. The comment is now updated with those. I didn't read in the post what you said its tldr is supposed to be; maybe I read over it
  - kijin 2y ago
    The practical benefit is virtually nil because HTTP already has a proven mechanism for caching and preloading. By the time you visit the second page on a multi-page site, you are likely to have almost all stylesheets, scripts, and common images already cached. This means you will reject almost all of the resource the server tries to push to you. Even on the first page, modern browsers are very quick to identify resources they need to load, both from headers and the early parts of the document. They load those resources concurrently while they are still parsing the document, so they are rarely blocked for a noticeable time. Meanwhile, single-page sites have evolved to a point where the entire application is contained in one or two heavily optimized, minified scripts. You just load that one script and you're done. Most small images these days are SVG embedded right in the source code, so again, there's little need to push other resources. The only time a modern website makes you to load a lot of unanticipated resources is when those resources are used for tracking and advertising. They can't be pushed because they live on different origins.
    - acdha 2y ago
      > Meanwhile, single-page sites have evolved to a point where the entire application is contained in one or two heavily optimized, minified scripts. You just load that one script and you're done. Most small images these days are SVG embedded right in the source code, so again, there's little need to push other resources. This isn’t true of most websites - look at the developer tools traces - because it’s terrible for performance to optimize for the IE6-era browser design. With those kind of bundles, you have to push a ton of content which didn’t change any time one byte of any resource changes. Since HTTP/2 substantially reduced the cost of multiple requests any site which has repeat visitors will benefit enormously from letting the bulk of the content which hadn’t changed be cached and only refetching the few responses which actually need to be updated.

mhitza 2y ago

> Why wasn't push adopted more widely? It wasn't given enough time, would be my guess. First Apache release that included HTTP2 support was in late 2015, same year HTTP2 RFC finished going through the process. In 2017 there still was browser inconsistency on how server push was handled (one of the reference articles in the sibling comment link). nginx implemented support for push somewhere around 2018 (based on wikipedia information). All those changes need to trickle down. Versions available in stable distros, config defaults etc. First time I've enabled http2 on my Apache servers, was in 2020 (and there are likely application servers out there that still don't support it directly in 2024).

znpy 2y ago

> It was one of the big reasons HTTP2 was meant to be a game changer Probably because it's a game changer only if you're at google/amazon/meta (or slightly smaller) scale. For everybody else its largely a huge complexity addition, and it's essentially ignored.

bawolff 2y ago
I suspect the issue is it wasn't really a game changer at google scale either.
- znpy 2y ago
  Yeah i kinda don’t trust google anymore on going good engineering work. Nowadays they look like the cushy job providers, like banks in the 80s (i guess)
KaiserPro 2y ago
We enabled HTTP2 in 2015 on the $big_financial_news_site. We had some influential JS people that were very keen to roll it out (they mostly ended up fastly after). I did warn that it would degrade all but the high bandwidth experience. It took a long time for them to "understand" the data, and that HTTP2 was not very useful, especially when compared the impact of changing CDN, or optimising for CDN caching.

JackSlateur 2y ago

Server push was never massively deployed because they may be harmful : the server pushes assets that may be needed by the client, but also may be already cached by the client. In the later case, this is a harmful burden, especially on mobile etc. The server is never able to truly know if the asset is actually required by the client Early hint is better, probably: the server quickly tells the client it will need those assets. The client can then decide if they must be fetched, or if they are already available.

alex_duf 2y ago

I looked into using this, but changed my mind. Say you get a hit on Index.html. you probably want to push script.js and style.css. So now you've pushed a few hundred kbits. Now, the user comes back and asks for index.html again: do you send everything again? Surely the resources are still in the user's cache. If you don't, how do you know what to send? Only the user's browser knows what's in can't and what's not. So you face the choice: speed up first visits but waste bandwidth for subsequent visits, out slow down first visits but speed up subsequent visits.

liveoneggs 2y ago

Can you explain the problem is solved better than Link headers, websockets, or SSE?

SahAssar 2y ago
Websockets and SSE are completely unrelated. Link headers can be used for preload, but until 103 Early Hints it could not be sent before the body content was processed on the server (unless your body content did not affect your headers, which is quite rare).

WhyNotHugo 2y ago

It’s really hard to architect around http push. Say I have a website in Python/Django, where I know that a page uses certain images. In order to use http push, my app would need to stream those images itself, rather than let a CDN or even Nginx do it. I suppose that some solution could have been implemented so that my Python app can tell nginx to stream certain static resources over a given connection… but the tools for that never surfaced. Most HTTP frameworks don’t support push.