4 ms·

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 oft

by 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.
pas 2y ago
in retrospect it seems the semantics got overcomplicated, which led to partial implementations (and of course many bugs and confusing and hard technical questions), which eventually led to implementation projects getting abandoned. and, probably in situations where the benefit of decreasing "time to first render" is big enough, there it makes sense to have a server that is coupled to the various low-level bits (load balancer connection tracking info, TLS session info, User Agent header, and Cookie of course) and for new sessions it can produce an optimized response payload.
dwaite 2y ago
My reasoning for never pursuing push is that a lot of semantics become implicit in the business requirements of the application itself. How does the server know it should push or not push data based on the client state, e.g. should it be pushing resources which could potentially already be in cache. That leads you to one of two paths: 1. The web content needed should be communicated to the server by the client; either requests are made with Fetch with additional parameters, or via a service worker which can then populate the cache itself. However, once you are supplying logic in the page to handle these resources, there are other approaches you can make - such as having a service worker populate the cache by downloading a single archive and unpacking it. 2. The other option would be for content which is specifically never meant to be cached, such as live updates of a sporting event. There is no API however to support this, and we already do have things like WebSocket to do this.

by Aachen 2y ago

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.

pas 2y ago

in retrospect it seems the semantics got overcomplicated, which led to partial implementations (and of course many bugs and confusing and hard technical questions), which eventually led to implementation projects getting abandoned. and, probably in situations where the benefit of decreasing "time to first render" is big enough, there it makes sense to have a server that is coupled to the various low-level bits (load balancer connection tracking info, TLS session info, User Agent header, and Cookie of course) and for new sessions it can produce an optimized response payload.

dwaite 2y ago

My reasoning for never pursuing push is that a lot of semantics become implicit in the business requirements of the application itself. How does the server know it should push or not push data based on the client state, e.g. should it be pushing resources which could potentially already be in cache. That leads you to one of two paths: 1. The web content needed should be communicated to the server by the client; either requests are made with Fetch with additional parameters, or via a service worker which can then populate the cache itself. However, once you are supplying logic in the page to handle these resources, there are other approaches you can make - such as having a service worker populate the cache by downloading a single archive and unpacking it. 2. The other option would be for content which is specifically never meant to be cached, such as live updates of a sporting event. There is no API however to support this, and we already do have things like WebSocket to do this.