In reference to:
HTTP/2 Server Push (the link: HTTP header) has been deprecated:
It is being replaced by 103 Early Hints:
Description
Description
Event Timeline
Comment Actions
Hi @adrelanos! Thanks for suggesting this.
We use preloads for the site logo indeed, in the form of a Link: rel=preload header emitted from CSS response. While the same CSS response also references the same site logo as a background image, browsers are by specification only expected to request that image until the matchihng DOM element has been found and rendered, which can be quite late. By emitting a preload header, we're informing the browser that we already know that it is definitely used on all pages and that it may start the request.
Note that when the browser follows our preload instruction, it does not always result in a network request. Preload instructions follow the same logic as regular requests for resources, which is to say, the browser will check its HTTP cache first and only make a network request if the cache has no valid entry (e.g. absent or expired).
The HTTP/2 push feature is different from HTML preloads. The MediaWiki software, and Wikipedia more broadly, does not currently make use of this feature. It is generally believed in the perf community today that HTTP/2 push can often be detrimental to performance. In theory a "push" has a slight benefit in latency, over HTML preload, as the server can start sending it even sooner, but this comes at the cost of the browser not being in control over the download and thus wasting valuable and limited bandwidth to transfer a resource the browser may very well already have in its cache. There is some propietary vendors like Cloudflare that experimented with converting a preload to an HTTP/2 push, but this is non-standard and not something we ever used.
The problem with HTTP/2 is why HTTP 103 was developed. However, as indicated, we don't use HTTP/2 push, and do not expect to need HTTP 103 at this point as preloads already achieve the same effect for us. The specific problem HTTP 103 solves is a problem we generally don't have, which is the delay between RTT and TTFB. Given that we own our CDN in-house and serve a majority cache hits, by the time we could send HTTP 103, we would have also sent the preload header already.
I'm closing this issue now from our workboard, but do feel free to follow-up here and ask if something is unclear or if I may have misunderstood you.
Comment Actions
Hello @Krinkle, thank you for your detailed answer, much appreciated!
We use preloads for the site logo indeed, in the form of a Link: rel=preload header emitted from CSS response.
I got confused by MediaWiki's Link: header not using nopush which I thought results in the default to use push and I am still not sure if that might happen. In all the blog posts I found on the topic, I always found rel=preload in relation to a discussion with HTTP/2 push. And if one wanted to use only preload, i.e. not using push, one would have to mandatorily add the nopush keyword.
I don't really understand how the HTTP Link Header syntax is different from preload / push / nopush. Seems to be both is used on the HTTP Link: header.
Prior the announcement of deprecation of HTTP/2 push, there might have been an argument to say "the nopush argument should be set" but I guess that doesn't matter now anymore since push is getting deprecated anyhow.
Comment Actions
To my knowledge, there is no formal relation between Link preload and HTTP/2 push.
Link preload headers are instructions to browsers, much like HTML link tags and script tags, with the main difference being that they are download-only without triggering style rendering or JS execution yet. In other words, they go from the server to the browser, and the browser then uses that preload instruction to make an actual request on its own back to the server.
HTTP/2 push on the other hand is something a web server does whereby it sends a response that was not (yet) requested. This was quite complex and unusual to do, so almost nobody did it. Cloudflare believed in the value of HTTP/2 push and so tried to improve people's websites by modiying it to send a push even if your website doesn't use it. One of the sources they used as inspiration for what to push was preload headers. Based on their custom code guessing what might be useful to push, and based on their tracking knowledge of your Internet connection speed and what previous requests you have made recently, their CDN software would then sometimes insert an HTTP/2 push to attempt to speed up your website. It was an interesting idea that connected two unrelated technologies. It was specific to Cloudflare afaik and indeed nopush is a non-standard mechanism they documented a way to op-out from their experiment.
It's interesting that to you they are so related. The only page I found where these are mentioned together is a Cloudflare blogpost. Although, it doesn't surprise me that they marketed it it widely to create this relation in people's minds.
I don't care much about Cloudflare, but note that they have since started a new experiment that creates automatic "HTTP 103 Early Hint" responses based on similar "sniffing" for preload links in your website. In other words, there is nothing to migrate even if you were using this. Typical backend applications send Link preload, and if your website would benefit from pushing or early hinting, then you can enable that on top of it (in Apache, Nginx, or some other proxy like Cloudflare) etc.
Anyway, preload has existed and is useful since before HTTP/2 push existed, and remains useful today in the same way it was already useful. Sorry for the confusion :)