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

81–90 of 142 posts

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

#81

Post by randomtree »

HTTP/2 Push allows to _really_ optimize first page load, giving a wow effect. (Especially when you can use a single server w/o geodns to serve the whole world with a really low latency!)

I use it on my pet project website, and it allows for a remarkable first page load time.

And I don't have to make all these old-school tricks, like inlining CSS & JS.

HTTP/2 Push allows for such a pleasant website development. You can have hundreds of images on the page, and normally, you'd be latency-bound to load it in a reasonable amount of time. And the way to solve it old-school is to merge them all into a one big image, and use CSS to use parts of the image instead of separate image URLs. This is an ugly solution for a latency problem. Push is so much better!

The fact that 99% of people are too lazy to learn a new trick shouldn't really hamstring people into using 30-year old tricks to get to a decent latency!

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

#82

Post by seanwilson »

johncolanduoni wrote: post #16
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…

Yes but inlining the critical CSS only for every page isn't trivial, and usually involves complicating your build chain.

I'm not saying there's a perfect solution, it's just interesting they're giving up on push.

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

#83

Post by seanwilson »

stock_toaster wrote: post #6
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.

Or use I guess (bonus: local caching still works).

You then have to wait for the preload content to arrive before your page starts to display though.

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

#84

Post by seanwilson »

jahewson wrote: post #49
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.

Server push arguably doesn’t bring caching benefits if you have to push the same CSS file as part of every request for any page. With browsers already able to eagerly parse out of the head and HTTP/2 multiplexing concurrent connections you’re looking at saving a single round-trip time, once and adding bandwidth overhead to every other request for a page.

There's no solution to fix this problem with push though by changing how push works? A single round trip is significant on slow mobile connections.

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

#85

Post by _flux »

fiddlerwoaroof wrote: post #38
nextaccountic wrote: post #34

Earlier quoted context omitted.

Do you mean that the same HTTP/1.1 GET request can have two different headers with two different status code? What's the reported status code of this response in typical libraries? Usually the status code is a single value and not a list.

10x status codes are already used for multipart requests and responses, right? 100 Continue and the like. This is usually handled transparently by your client library.

I'm going to assume many HTTP libraries and ad-hoc implementations expect one HTTP response for one HTTP request (but still support pipelining) and will break if this underlying assumption changes.

In fact, this may even be ratified in the interfaces they provide: think synchronous "give contents of this URL" functions.

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

#86

Post by seanwilson »

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.

This is like when people complain about legacy code they first see it without understanding the context the code was written in. Or saying C coding is safe if everyone was just more careful and more skilled.

It's just not true that it's super easy to write fast pages. There's a huge amount of background you need to understand to optimize fonts, images, CSS, your server, your CMS, caching, scripts etc. There's multiple approaches for everything with different tradeoffs.

Even if you have the skills to do this solo, you might not have the budget or the time or the approval of management. Big websites also require you to collaborate with different developers with different skillsets with different goals, and you need to keep people in sales, graphic design, SEO, analytics, security etc. roles happy too.

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

#87

Post by pa7x1 »

psanford wrote: post #14
gravypod wrote: post #5

Earlier quoted context omitted.

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.

This 100%. There is so much confusion between HTTP/2 Push and and HTTP/2 bidirectional streaming capabilities, I personally had to go back to the Spec. to understand the difference because a lot of material just mixes them together. They are not the same thing.

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

#88

Post by Town0 »

ioquatix wrote: post #45
Town0 wrote: post #30

Earlier quoted context omitted.

Yes and I'd describe them as unpopular hacks. Http2 push is not a hack.

Actually... I've implemented both client and server side HTTP/2 push and I'd say... it's a hack and we should deprecate it and remove it from the spec.

Here's another idea: A user is expected to flip quickly through pages after a quick evaluation of each page. Server push makes flipping the pages instant, and the hit rare is 80% at least.

Server push is extremely elegant, though it competes with more complex (scripting) approaches which the Valley hipster crowd adores. Usually that crowd lacks any hint of imagination, but they're not the only ones building technology solutions.

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

#89

Post by kdunglas »

Server Push has a use case for web APIs. I just published a benchmark showing that under certain conditions APIs using Server Push (such as APIs implementing the https://vulcain.rocks specification) can be 4x times faster than APIs generating compound documents (GraphQL-like): https://github.com/dunglas/api-parallelism-benchmark

They key point for performance is to send relations in parallel in separate HTTP streams. Even without Server Push Vulcain-like APIs are still faster than APIs relying on compound documents thanks to Preload links and to HTTP/2 / HTTP/3 multiplexing.

Using Preload links also fixes the over-pushing problem (pushing a relation already in a server-side or client-side cache), some limitations regarding authorization (by default most servers don't propagate the Authorization HTTP header nor cookies in the push request), and and is easier to implement.

(By the way Preload links were supported from day 1 by the Vulcain Gateway Server.)

However, using Preload links introduce a bit more latency than using Server Push. Does the theoretical performance gain is worth the added complexity? To be honest I don't know. I guess it doesn't.

Using Preload links combined with Early Hints (the 103 status code - RFC 8297) may totally remove the need for Server Push. And Early Hints are way easier than Server Push to implement (it's even possible in PHP!).

Unfortunately browsers don't support Early Hints yet.

- Chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=671310

- Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1407355

For the API use case, it would be nice that Blink adds support of Early Hints before killing Server Push!

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

#90

Post by josephg »

ahupp wrote: post #13
gravypod wrote: post #5

Earlier quoted context omitted.

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.

Websockets are different again from both server push and h2 streams. Server push was a feature added in http2 for populating the browser’s cache. Websockets are an http/1.1 extension for tcp-like bidirectional messaging.

Server push, websockets, h2 steams and webtransport are all different things.

Post reply on HN