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

Hi, and thanks for the feedback.

I'm aware of this "issue" (I must mention it in the repo, and I will). However, I don't think that it matters much for a web API: in most cases, inside web browsers, the TCP connection will already be "warmed" when the browser will send the first (and subsequent) requests to the API, because the browser will have loaded the HTML page, the JS code etc, usually from the same origin. And even if it isn't the case (mobile apps, API served from a third-party origin...) only the firsts requests will have to "warm" the connection (it doesn't matter if you use compound or atomic documents then), all subsequent requests, during the lifetime of the TCP connection, will use a "warmed" connection.

Or am I missing something?

Anyway, a PR to improve this benchmark (which aims at measuring the difference - if any - between serving atomic documents vs serving compound documents in real-life use cases) and show all cases will be very welcome!

What you say would be true if images/js/css is truely served by the same IP adresse (not hostname!). In reality, people use CDNs to deliver the static assets like images/js/css, and only the API calls are used to warm up the TCP connection to the actuall data backend. Also things like DNS load-balancing would break the warm up, because the congestion control caches operate on IPs, not hostnames.

Additionally, its really hard to benchmark and claim it is "faster". You will always measure using the same networking conditions (latency, packet loss rate, bandwidth). So if a benchmark between two machines yields faster results using technology A, the same benchmark may return complete different results for different link paramters. Point being: Optimizing for a single set of link parameters is unfeasible, you'd have to vary networking link conditions and find some kind of metric to determine what means "fast": Average across all paraters? Or rather weighted averages depending on your 98th percentile of your userbase etc.

Regarding improving the benchmarks: It is really hard, since (a) docker images cannot really modify TCP stack settings on the docker host and (b) client and server would have to flush their TCP congestion control caches at the same time, and only after both flushed the next run can be conducted.

EDIT: Regarding serving static assets to warm up the connection: In that case, you'd have to include page-load time to download that assets in your meassurement (including time to parse+execute JS) and overall time comparison. Switching the API prototocol from REST to something else will probably not have that big of an impact on the total load time then. Saying: If you spend 80% of your time downloading index.html, css, some javascript etc. and querying your API accounts only 20% of the time, you will only be able to optimized on that 20%. Even if you cut load times for the API calls in half, overall speedup for the whole page load would be 10%.

The intent is to allow even earlier preloading than what `Link` headers in the response or `` in the HTML would typically allow. The insight here is that most application servers/webservers get a request and only send the response headers all at once, with the body, once everything is ready. But many times you already know some static resources ahead of time, before you know what response to send back.

For example, if you make a request for `GET /users/id/12345`, you know the user probably needs `style.css` like most do. You put that into a `Link` header in the response. But the browser won't fetch that file until it is told about it. It will only be told about it once it has seen the entire response, because again, the server (probably) sends it all at once, body and headers together, anyway.

But, producing that page in the first place may require running database queries for user info, your template engine to get run for the page body, an external HTTP call to happen in the background for their Gravatar, etc. So all of that has to happen on the server side before style.css can be fetched by the client browser. Even though you (the developer) knew they (the client) probably needed it. Let's say that `GET` request needs 500ms of computation (DB query + API call) before a reply is sent. That means the client has to wait at least 500ms for the server to produce any Link headers -- 500ms before it can fetch style.css. More importantly, it's literally 500ms where the client browser does nothing while it waits, while it could be concurrently downloading other assets, for example.

With Early Hints, when someone issues a `GET /users/id/12345`, the server can immediately reply using an Early Hint and tell the client about style.css first-thing. Then the client can immediately go fetch style.css, without waiting 500ms for the server to produce the body, or the headers, or even anything at all.

One interesting advantage of this is that, like Link headers, but unlike Server Push, early hints can be statically computed at at "application build time." You just need a mapping of URIs to URIs, like preload. So you can imagine for example your Django Middleware or Rails App or NodeJS Thing-Doer might have a step where it calculate asset dependencies for your frontend, and has a middleware layer that automatically issues 103 Early Hints for statically known page assets. And unlike Push, Early Hints are client-controlled. A big problem with Push is that it has no knowledge of the client-side cache, so it can push assets unnecessarily and cause slowdown. Early hints has no such drawback; the client has complete knowledge of its cache state and can make the correct decision.

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

Looking at their highly optimized code on google.com, my guess is that they already use all the tricks that work on _every_ browser. And it might not make much sense for them to have two builds: one elegant, with multiple files per page for newer browsers, and ugly optimized blob for older ones.