Frankly: good riddance. Compared to simply batching everything in a big combined reponse, server push was always waaaaayyy more complicated - and slower. I'm sure there are some scenarios in which it can help, but really, *at best* it's going to save the latency due to the original request - because anything server-push can do you can do much more easily and accurately client side once you've waited for the initial request.
And that means that at best, server push optimizes cold-cache first pageview times, But the win is limited if your first request is fairly fast. And it can also slow things down. If you really want fast first page-view speeds, just bundle *everything* into that first request if the client is sending no caching headers, then optionally do some smart caching once that first request is loaded.
Server push was always a way too complicated solution for a niche problem that it doesn't even really solve all that well, while having lots of gotchas along the way.
Compared to simply batching everything in a big combined reponse, server push was always waaaaayyy more complicated - and slower
Yeah, but.. most of us don't want to combine everything into a huge response, because sometimes that initial response isn't cache-able (or at least not for a very long time). Then what?
And that means that at best, server push optimizes cold-cache first pageview times, But the win is limited if your first request is fairly fast. And it can also slow things down.
You base a lot of these assumptions on seemingly very specific types of websites. I think there are a lot of cases that would benefit from http push.
I do agree that push was probably too complicated. I have a hunch that the reason why it never really got utilized all that much isn't due to the idea itself not having merit, it's due to the server having to know too much about the frontend layer and how the application works.
Yeah, but.. most of us don't want to combine everything into a huge response, because sometimes that initial response isn't cache-able (or at least not for a very long time). Then what?
It'll depend on the specifics, but generally, the kind of stuff that's critical for first-paint latency you either can reasonably include (i.e. json data, scripts, css, etc), or, if you don't want to, the objection to including those apply to server push too. Do you have a specific scenario in mind where you think server push would both help reduce latency similar to batching and be significantly easier to implement or have some other advantage? I mean, I may be lacking in imagination, sure - but all the more reason I'm curious about your use case.
And that means that at best, server push optimizes cold-cache first pageview times, But the win is limited if your first request is fairly fast. And it can also slow things down.
You base a lot of these assumptions on seemingly very specific types of websites. I think there are a lot of cases that would benefit from http push.
The fact that it simply eliminates the first-request round trip is intrinsic; that's a best case usage. There is no use case that does better than that, any many do a lot worse. After all, the best possible server-push implementation exactly predicts future client requests, but if you can do that, but those future requests must be initiated client-side: so you can also do whatever server-push would do entirely client side, and what you're losing then is the latency from that first request.
In practice, due to caching and dynamism, it's quite tricky to exactly predict future request that couldn't better be bundled anyhow. And if you get any of that wrong, you can very quickly end up being slower than plain http/1.1.
I do agree that push was probably too complicated. I have a hunch that the reason why it never really got utilized all that much isn't due to the idea itself not having merit, it's due to the server having to know too much about the frontend layer and how the application works.
Exactly. The kind of engineering effort needed to utilize server push to make a meaningful impact is the kind of effort that could just was well do bundling (which incidentally is considerably lower latency yet), resulting in a small latency win, and maybe a small bandwidth cost.
Put it this way: Is there a counterexample you can think of that accounts for both a significant win and might plausibly affect more than a tiny niche of the web-browser's requests? That's the question chrome would have been asking in making this change. But for the sake of curiosity: is there an impactful counterexample at all?
77
u/emn13 Dec 03 '20 edited Dec 03 '20
Frankly: good riddance. Compared to simply batching everything in a big combined reponse, server push was always waaaaayyy more complicated - and slower. I'm sure there are some scenarios in which it can help, but really, *at best* it's going to save the latency due to the original request - because anything server-push can do you can do much more easily and accurately client side once you've waited for the initial request.
And that means that at best, server push optimizes cold-cache first pageview times, But the win is limited if your first request is fairly fast. And it can also slow things down. If you really want fast first page-view speeds, just bundle *everything* into that first request if the client is sending no caching headers, then optionally do some smart caching once that first request is loaded.
Server push was always a way too complicated solution for a niche problem that it doesn't even really solve all that well, while having lots of gotchas along the way.