This and so much this. I also worked with HTTP/2 (when it was still a SPDY draft) and came to the same conclusions: TCP peculiarities (most notably congestion control and its dynamic window scaling) mostly eradicate the benefits of HTTP/2. HTTP/1.1 was using 5-6 different TCP connections (which re-use OS level window scaling caches), while HTTP/2 you had to transfer all resources through a single TCP connection.

People often claim HTTP/2 to be superior due to its multiplexing capabilities, but always reason with the mental model of having true stream-based flows and leaving TCP completely out of the argument loop. But guess what, that model is just a model, indeed you have packet-based TCP flows that are abstracted away to mimic a continuous stream as a socket - and those matter.

Building a compagny arround a very specific tech not finalized seems very risky.

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...

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

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 essential" and at the same time not really working need to be kept, just because they're in a standard. if it was essential I'd view it differently, but in this case I hope it gets dropped.

I tend to disagree. Server push was a cool way for implementing streaming like in hls particularly when you have constrained devices that otherwise would suffer from request latencies.

However, IMHO the Internet has mostly degraded to a huge CDN. Http/2 is often not even handled by the final end point. Decentralized caching and proactive cache control has become a niche.

Having said that, I still dream of a world in which browsers just care about rendering, rather than defacto shaping the future arch of the net on all layers (DoH, https cert policies, quic MTUs, ...)

Note that this is also available via the `Link:` HTTP header. This means that you can get the preload hint to the browser quite early so there shouldn't be too much delay before it makes the request.

Of course if your HTML is small it may still be slightly slower than push. However the advantage is that you don't push cached resources over and over again.

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?

Even before HTTP/2 was standardised there were some strong arguments by Mike Belshe (co-creater of SPDY) and others that we should drop push

But it never happened and so made it into the H2 standard

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 will be very sceptical about all "real world usage" statistic claims from Google.

For people like me who are unfamiliar with the proposal, 103 Early Hints [1] would work like this.

Client request:

  GET / HTTP/1.1
  Host: example.com

Server response:

  HTTP/1.1 103 Early Hints
  Link: </style.css>; rel=preload; as=style
  Link: </script.js>; rel=preload; as=script
  
  HTTP/1.1 200 OK
  Date: Fri, 26 May 2017 10:02:11 GMT
  Content-Length: 1234
  Content-Type: text/html; charset=utf-8
  Link: </style.css>; rel=preload; as=style
  Link: </script.js>; rel=preload; as=script
  
  <!doctype html>
  [... rest of the response body is omitted from the example ...]

[1]: https://tools.ietf.org/html/rfc8297

I'm not sure if i see much benefit over just having a header on the 200 response. I suppose if it takes a bunch of time to generate the response body, but most of the time where this sort of thing would make a difference you probably already have the response body for the main request cached on the server side.

And I can't understand why!

gRPC does not use PUSH_PROMISE frames.

I guess you could see if the client has a cookie, and infer cache state from that.

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.

> your resources are small and load quickly

Size is only semi-related to latency. For small resources, latency costs dominate. That's what push addresses.

> 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!

What amazes me is that in this <1% there is not even Google, which implemented push in its own protocol. Any insights on that?

Would inlining CSS and JS work on web sites (not apps)? I kinda feel inlined JS will bypass bytecode cache and the parsing costs have to be paid on each page load.

Sorry we can’t boil the ocean to preserve your nice dev experience. Welcome to building for the web. Those old tricks exist for a reason: it’s not the client’s problem, it’s your problem.

CDNs loved the idea of HTTP/2 push. It's a complicated low level feature. To make it work, you'd need to figure out what to push, and the ideal way to prioritise and multiplex those streams to optimise for first render. CDNs are in the business of knowing this stuff better than anyone else, yet they still couldn't make it work.

Remember, most sites using CDNs still go to the root server for HTML and other no-cache content. It's only the more optimised sites that figure out how to deliver those resources straight from the CDN without consulting the end server.

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-...

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.

I'm sorry to disappoint you, but your benchmark methodology is flawed. You did not consider TCP congestion control/window scaling. TCP connections between to peers are "cold" (=slow) after the 3-way handshake, and it takes several roundtrips to "warm" them up (allow data to be sent at a level that saturates your bandwidth). The mistake you (and most other people performing HTTP load benchmarks) made, is that the Kernel (Linux, but also all other major OS Kernels) caches the state of the "warm" connection based on the IP adress. So basically, when you run this kind of benchmark with 1000 subsequent runs, only your first run uses a "cold" TCP connection. All other 999 runs will re-use the cached TCP congestion control send window, and start with a "hot" connection.

The bad news: For website requests <2MB, you spend most of your time waiting for the round-trips to complete, say: you spend most of the time warming up the TCP connection. So its very likely that if you redo your benchmarks clearing the window cache between runs (google tcp_no_metrics_save) you will get completely different results.

Here is an analogy: If you want to compare the acceleration of 2 cars, you would have race them from point A to point B starting at a velocity of 0mph at point A, and measure the time it takes to reach to point B. In your benchmark, you basically allowed the cars to start 100 meters before point A, and will measure the time it takes between passing point A and B. Frankly, for cars, acceleration decreases with increasing velocity; for TCP its the other way around: the amount of data allowed to send on a round trip gets larger with every rountrip (usually somewhat exponentially).

you can push now using headers or custom vcl with fastly:

https://docs.fastly.com/en/guides/http2-server-push

> But I do not see support as optional.

That's funny, given the HTTP/2 RFC does see the support as optional.

Is there an example of http/2 push being used usefully? I haven't seen one, but would be happy to take a look.

If it's not useful, why keep support for it?

As I recall, Google added this push in spdy, so it makes sense for them to be the ones to push for it to be removed.

LL-HLS removed HTTP/2 Server Push from the spec back in January: https://mux.com/blog/low-latency-hls-part-2/

This was driven by poor server + client support at large, and the complexity it introduced. LL-HLS instead uses byte ranges and open-ended ranges over HTTP/2 - almost Comet-style - to handle CMAF chunks.

The post does say:

> It is interesting to note that server push has been used in ways other than originally intended. One prominent example is to stream data from the server to the client, which will be better served by the upcoming WebTransport protocol.

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 :-(

Web transport isn’t used for transferring HTTP requests/responses by the browser. It’s essentially an expansion of WebSockets to include multiple streams and optional UDP-like delivery, while still being encapsulated in HTTP/3 and suitable to be called by JS. Server sent events similarly only works if you have JS on the client receiving it, the browser doesn’t know how to render the events inherently.

> Do web-transport obscolete push?

No, it solves a completely different problem.

HTTP/2 Server Push is a mechanism where the server can send HTTP responses for resources it believes the client will need soon. (For example, if a client has just requested a web page with a bunch of images on it, the server could use Push to send those images without having to wait for the client to encounter the image tags and request the associated image resources.)

“Notifying the server” is already done by browsers by just making a regular request. Prefetching links has been a thing for a while now. You don’t need HTTP/2 to do it.

This is a really weird system you have devised.

You are making a custom request to ask the server to push something to the browser.

Browser: POST /preload?url=/next-page Server: PUSH /next-page

Just cut out the middleman and make a regular request.

Browser: GET /next-page

Even better use browser preloading mechanisms so that the browser knows how to best prioritize them. In fact if you do it this way the browser can even start downloading subresources and prerendering the page.

From what i understand the push cache gets deleted the moment the http connection is closed, which to me makes it sound not the most suitable for this.

Maybe just adding a rel=preload link tag dynamically would be better (do link tags work dynamically? I have no idea). Or just fetching with normal ajax and use a service worker.

There are libraries [1] that achieve what you describe.

[1]: http://instantclick.io/ "InstantClick"

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.

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 <link preload> 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.

I would think the best option would still be to have the css in a separate file unless your css is very small. It is of course a tradeoff between if the extra RTT hurts you more than the extra bytes in your page (how much that matters depends on how big your page is and tcp window sizes), and how often your users are viewing your website totally uncached.

Keep in mind, that even without server push http/2 still fixes head of line blocking which was a major reason that the folk wisdom of inlining things and using sprites popped up in the first place.

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).

Or use <link rel="preload"> I guess (bonus: local caching still works).