Just switch to FireFox, its faster, more secure and more advanced when it comes to GDPR anyway.
I red this last year somewhen and was also confused about the “reason” is just not valid.
Like someone banns Kitchenknifes because one was somewhen somehow from someone used to kill a someone. So they project a very small usecase and just the worst of it to ban it.
Thats like 10 steps backwards. If you see things are getting used/abused in a way they never has been created for AND it is bad then you actually should come up with a Update or whatevery, but not with banning them.
Its like bad politicians:
if they cant deal with something they just define its bad and thats it…
So if someone decided to ban/remove something this person just shows that it probably exceeded their mental capacity/limit and therefore this is the only way (for them) to solve it.
Also they never mentioned that HTTP2/Push can remove a lot of renderblocking and therefore is often used on CSS files to deliver them with the same request as the DOM to render immediately.
I dont fear the moment when tehy remove it its just that I think its stupid not to really solve problems that may occure but remove the whole functionallity because it could be used in a way that is not good for the users experiance.
Also the writer of this Blog was clearly analysing the change like this:
Following Chrome’s announcement, I decided to remove server push from Ctrl blog. It’s still supported in all the leading web browsers, but it’s effectively dead once Chrome pulls the plug. One week after removing it from the site, the performance impact is clear: the median time to first contentful paint (FCP) has increased by 10 % (adding roughly 100 milliseconds). Ouch.
He also stated how to achive a somewhat similar result:
The stylesheet-pushing, combined with deferred script-loading, has ensured that pages have been rendered as quickly as possible. After the deprecation of server push, the only open-web way to get similar results is to include the stylesheet inline/embedded in the HTML documents (“inlining”). Inlined resources don’t benefit from the shared cache, though, so you end up wasting bandwidth the same way you do with needless server pushed resources.
So seems that HTTP2/Push was exactly doing what it was supposed to do:
speeding up PageLoad.
IMHO: it’s a bad decision to remove it!
Like stated here:
https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYLvmQUBY/m/vOWBKZGoAQAJ
There are alternatives… but I feel like someone takes away my car and states that walking is an alternative… yes it is but its not as alternative that is as good as driving car.
Alternatives:
-
<link rel="preload"> is not as fast as HTTP2/Push as it is 1RTT slower
-
HTTP Code 103 Early Hints is also not as fast as HTTP2/Push as it needs an additional request
So they remove a function which they can not replace. Also one of the resons they use it was “not enough people used it” was is no valid reason to remove it.