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

71–80 of 142 posts

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

#71

Post by sepples »

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.

Typical page loads were much slower two decades ago than they are today by my recollection, unless you were lucky enough to have something better than 56k dialup.

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

#72

Post by skissane »

johncolanduoni wrote: post #65
skissane wrote: post #64

Earlier quoted context omitted.

> There are impractical, camel-like, and downright bizarre IETF standards but these are bad examples I'd love to know which RFCs you'd call "camel-like"

I was referring to "a camel is a horse designed by committee" :P

I was asking which IETF standards you would describe by that phrase.

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

#73

Post by londons_explore »

FeepingCreature wrote: post #63

Why doesn't the client keep a bloom filter of already-requested URLs on that website and send it along to the server on the first request? That way, you'd get the less-space benefit of link rel, but the latency benefit of push. Also, this is very Google: "Well, few people have adopted it over five years, time to remove it." HTTPS is almost as old as HTTP and is only now starting to become universal. Google has no pat…

The bloom filter seems like the obvious solution!

I even spent the best part of a week back in 2017 trying to build a bloom filter into Chrome's HTTP cache so each connection could send to the server a tiny filter of the resources already cached, and then the server could send back a package of "everything needed to render the page you have requested". Turns out the HTTP cache is complex so I gave up.

If fully implemented, it ought to be able to cut render times dramatically, and to eclipse the performance benefit of cdn's (where the main benefit is reducing latency for static assets).

There are potential privacy concerns, but no moreso than first party cookies.

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

#74

Post by cookiengineer »

jaffathecake wrote: post #60

I think this is the right decision. I looked at HTTP/2 push in 2017 and the design is very confusing, and the implementations are pretty bad. https://jakearchibald.com/2017/h2-push-tougher-than-i-though... . Chrome's implementation was best, but the design of HTTP/2 push makes it really hard to do the right thing. Not just when it comes to pushing resources unnecessarily, but also delaying the delivery of higher prio…

Do you know maybe whether there are similar adoption rates in HTTP/3?

As someone that implemented http/1.1 almost feature complete [1], I think that the real problem on the web is the missing of a testsuite.

There needs to be a testsuite for http that both clients and servers can test against, and that is not tied to internal codes of a web browser.

I say this because even a simple spec like 206 with multiple range requests literally never is supported by any web server. Even Nginx, apache or google's own dns over https servers behave differently if the request headers expect multiple response bodies. Let alone the unpredictability of chunked encodings, which is another nightmare.

I really think that there should be an official testsuite that is maintained to reflect the specifications, similar to the intention of the (meanwhile outdated) acid tests.

Adoption rates to new http versions will always stay low if you implement it for months exactly as the spec says, just to figure out that no real world webserver actually implements it in the same way.

[1] https://github.com/tholian-network/stealth/blob/X0/stealth/s...

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

#75

Post by londons_explore »

yc12340 wrote: post #59

HTTP/2 server push is odd. When you can get the most benefit out of it, you usually don't care, because your resources are small and load quickly anyway. And when you care (because your resources are big don't load quickly enough), HTTP push actually hurts you, because you are pushing the same big resource on every page load. I have tried to use it once, and the hassle of distinguishing between first time visits and…

I think the benefits are where some automated system writes your "preload" entries for you.

For example, a webpack stage could render inside a sandbox each page of your site, detect which resources get loaded, and add all of those as preload/server push entries. The server itself can keep records of which resources have been pushed to a specific client, and not push them again.

Writing preload lists by hand is never going to scale with today's web apps with hundreds or thousands of requests for a typical page.

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

#76

Post by londons_explore »

francislavoie wrote: post #53

Well that sucks. Caddy has supported HTTP/2 push for a very long time (except for a few months after v2 was released since it was a total rewrite). https://caddyserver.com/docs/caddyfile/directives/push

I just finished 3 weeks implementing server push for my web app which cuts typical load times in half :-(.

I guess I'll have to go back to putting all the images base64 encoded into the html :-(

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

#77

Post by DarkWiiPlayer »

throwaway189262 wrote: post #66
jaffathecake wrote: post #60

I think this is the right decision. I looked at HTTP/2 push in 2017 and the design is very confusing, and the implementations are pretty bad. https://jakearchibald.com/2017/h2-push-tougher-than-i-though... . Chrome's implementation was best, but the design of HTTP/2 push makes it really hard to do the right thing. Not just when it comes to pushing resources unnecessarily, but also delaying the delivery of higher prio…

Agree 100% . I never saw a use for server push. I'm glad to see unused features go, web browsers are far too bloated already. The web would be fine if they stopped adding features today for the next 10 years. The massive complexity of the browser will eventually be a detriment to the platform

When Server Push became a thing, I liked the idea quite a lot, and I find it somewhat sad to see it disappear again, but realistically speaking, it wasn't used that much, so it might be for the best to just let it go.

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

#78

Post by sanxiyn »

FeepingCreature wrote: post #63

Why doesn't the client keep a bloom filter of already-requested URLs on that website and send it along to the server on the first request? That way, you'd get the less-space benefit of link rel, but the latency benefit of push. Also, this is very Google: "Well, few people have adopted it over five years, time to remove it." HTTPS is almost as old as HTTP and is only now starting to become universal. Google has no pat…

Bloom filter is indeed a sufficiently obvious idea that it got already proposed. But it wasn't accepted and was expired in 2019. See Cache Digests for HTTP/2.

https://tools.ietf.org/html/draft-ietf-httpbis-cache-digest-...

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

#79

Post by vbezhenar »

locallost wrote: post #69
jaffathecake wrote: post #60

I think this is the right decision. I looked at HTTP/2 push in 2017 and the design is very confusing, and the implementations are pretty bad. https://jakearchibald.com/2017/h2-push-tougher-than-i-though... . Chrome's implementation was best, but the design of HTTP/2 push makes it really hard to do the right thing. Not just when it comes to pushing resources unnecessarily, but also delaying the delivery of higher prio…

thanks for that post. that and some other resources convinced me then that my time is better spent elsewhere. in the post it says less then .1% connections in Chrome receive a push event. some people will always try out the cutting edge, but the fact it hasn't spread after several years is a pretty good indicator that it's not producing the expected results. I don't know why things that are "nice to have, but not ess…

Web was always about backwards compatibility. You should be able to contact with HTTP web server deployed in 1995 from modern web browser.

Server push is different, because it's supposed to be an invisible optimization, so it could be dropped without anyone noticing. But most things are not invisible.

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

#80

Post by dsign »

Five years ago, we built a company around HTTP/2 server push. Here is what we learned:

- The interaction of HTTP/2 push with browser caches were left unspecified for the most part, and browsers implemented different ad-hoc policies.

- Safari in particular was pretty bad.

- Since HTTP/2 Push worked at a different layer than the rest of a web application, our offering centered around reverse-engineering traffic patterns, with the help of statistics and machine learning. We would find the resources which were more often not cached, and push those.

- HTTP/2 Push, when well implemented, offered reductions in time to DOMContentLoaded in the order of 5 to 30%. However, web traffic is noisy and visitors fall in many different buckets by network connection type and latency. Finding that 5% to 30% performance gain required looking to those buckets. And, DOMContentLoaded doesn't include image loading, and those dominated the overall page loading time.

- As the size of, say, Javascript increases, the gains from using HTTP/2 Push asymptotically tend to zero.

- The PUSH_PROMISE packets did indeed could increase loading time because they needed to be sent when the TCP connection was still cold. At that point in time, each byte costs more latency-wise.

- If a pushed resource was not matched or not needed, the loaded time increased again.

Being a tiny company, we eventually moved on and found other ways of decreasing loading times that were easier for us to implement and maintain and also easier to explain to our customers.

Post reply on HN