Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blink: Intent to Remove: HTTP/2 and gQUIC server push

groups.google.com

Post reply on HN
Print view View original

11–20 of 142 posts

Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push

#11

Post by AnIdiotOnTheNet »

userbinator wrote: post #9
seanwilson wrote: post #4

So instead of pursuing the idea of server pushing your CSS so the top of your page renders fast, the best option is to inline CSS directly into the page but lose caching benefits between pages? Crafting a fast website is going to be messy and difficult for a good while still.

A "fast website" is super-easy to create if you don't add dozens of megabytes of useless crap to each page. Two decades ago: hardware was slower, bandwidth was far more constrained, and browsers didn't have so many features nor take up so much resources --- and yet the speed of page loading was often much better than it is today! Indeed, most of the "problems" web developers complain about are self-inflicted.

Things weren't just slower, they were orders of magnitude slower. It's ridiculous how we've managed to make computers ludicrously fast and the developer response has been to keep adding garbage until they are slow again.

Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push

#12

Post by tialaramex »

stock_toaster wrote: post #3
xyzzy_plugh wrote: post #2

This is pretty funny. After all the fuss, turns out that server push isn't really useful. I'm half impressed that they are able to actually admit they were wrong (implicitly of course) by removing it. I can't say I'm surprised, either. I could never think of a reasonable use case for it. With the variety of streaming options available now, it really seems antiquated.

It's too bad they didn't realize it sooner, or it could have been removed from HTTP/3 before IETF finalizes it. Probably too late now?

It's currently in Last Call, but if there's consensus to modify HTTP/3 that can be done at any point, although obviously doing it after it's actually published would be in the form of errata or a -bis RFC that modifies the standard. It's not extraordinary for something which has consensus to get done really late, even in AUTH48 (a notional "48 hours" for the authors of the document to fix any last little things that often lasts rather longer than two Earth days) if that's what people decide is necessary.

But "Blink doesn't want to do it" isn't consensus on its own, this page suggests other clients implement this and offers no opinion about whether they intend to likewise deprecate the feature.

Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push

#13

Post by ahupp »

gravypod wrote: post #5
xyzzy_plugh wrote: post #2

This is pretty funny. After all the fuss, turns out that server push isn't really useful. I'm half impressed that they are able to actually admit they were wrong (implicitly of course) by removing it. I can't say I'm surprised, either. I could never think of a reasonable use case for it. With the variety of streaming options available now, it really seems antiquated.

Server push is quite useful for bidirectional streaming of data which is heavily used in gRPC to help reduce latency and shovel large amounts of data.

I think this is different than server push like WebSockets; this is all about pushing down resources the server suspects you'll need.

Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push

#14

Post by psanford »

gravypod wrote: post #5
xyzzy_plugh wrote: post #2

This is pretty funny. After all the fuss, turns out that server push isn't really useful. I'm half impressed that they are able to actually admit they were wrong (implicitly of course) by removing it. I can't say I'm surprised, either. I could never think of a reasonable use case for it. With the variety of streaming options available now, it really seems antiquated.

Server push is quite useful for bidirectional streaming of data which is heavily used in gRPC to help reduce latency and shovel large amounts of data.

gRPC does not use PUSH_PROMISE. It uses HTTP/2 streams, but those streams all get initiated by the client.

Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push

#15

Post by psanford »

simscitizen wrote: post #7

Server push never made any sense anyway for most subresources. The server doesn't know about the state of the browser's cache, so using server push for a subresource could cause it to needlessly push a subresource that was already cached by the browser. Maybe it is useful outside of the browser context, e.g. in gRPC.

gRPC does not use PUSH_PROMISE frames.

Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push

#16

Post by johncolanduoni »

seanwilson wrote: post #4

So instead of pursuing the idea of server pushing your CSS so the top of your page renders fast, the best option is to inline CSS directly into the page but lose caching benefits between pages? Crafting a fast website is going to be messy and difficult for a good while still.

Well the best thing is to in-line only the CSS needed for content actually in the server render if it’s much smaller than total site CSS. If you’re code splitting your CSS in the first place this is usually handled pretty well by the same mechanism. Then CSS is still cacheable across page loads for later navigation (particularly if you use a ServiceWorker in lieu of server rendering once enough core assets are cached).

Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push

#19

Post by johncolanduoni »

userbinator wrote: post #9
seanwilson wrote: post #4

So instead of pursuing the idea of server pushing your CSS so the top of your page renders fast, the best option is to inline CSS directly into the page but lose caching benefits between pages? Crafting a fast website is going to be messy and difficult for a good while still.

A "fast website" is super-easy to create if you don't add dozens of megabytes of useless crap to each page. Two decades ago: hardware was slower, bandwidth was far more constrained, and browsers didn't have so many features nor take up so much resources --- and yet the speed of page loading was often much better than it is today! Indeed, most of the "problems" web developers complain about are self-inflicted.

I’ve shipped almost pure HTML landing pages (Single kBs of total JS, none of it render blocking) in the last few years, and inline CSS and preload headers help a lot, especially for older devices. Expectations for image/video resolutions in particular have gone up since “the good old days”. You can really see the effect with much older devices, which become the majority once you look outside the US and EU.

IME most people trying to optimize their way out of tag manager, monolithic SPA hell don’t generally bother with these kind of features outside of turning on all the cloudflare rewriting and praying. If performance was important to them and they knew what they were doing, they’d fix those first.

Post reply on HN