Yep, hopefully a lot of the default improvements will make their way into all of the browsers. Until then, this also evens the field across all of the browsers but for me the really exciting part is exposing it to Workers so sites can customize the logic specific to their needs. Boosting the priority of hero images or async scripts that are important for the site but the browser's default logic has no way to know. Priority hints (also Chrome-only currently) will eventually bring that to browsers natively.

Full disclosure, I'm the article author and I also spent several years on the Chrome team working on the resource loading/scheduler so it's probably not too surprising that there are similarities.

From my understanding the better policy will be to prioritise the smallest assets first. To me it seems counter-intuitive but apparently it proves out in theory and testing: https://www.cs.cmu.edu/~harchol/Papers/usits1.pdf

More dramatic improvement might be possible if streams can be interrupted and resumed (which is something protocols like RSocket support): https://www.cs.cmu.edu/~harchol/Papers/MIT-LCS-TR-767.pdf

Apologies if you're already familiar with these.

These papers are interesting, thanks for sharing.

However, the primary axiom is of a web server that is serving static content that is located on the device. That, in a sense, gives almost infinite time and knowledge to deciding prioritisation of work.

For HTTP proxies that have to fetch resources from some other server, the time and knowledge window becomes much shorter. Decision making needs to be done quickly in order to minimise the latency of returning anything. And the upstream server may response in unexpected ways.

This is the challenge for today's CDN deployments. And developing a solution that works for the huge variety of how websites are developed is the really interesting bit.

I'm not sure I follow. Proxies don't have much time to reorder from an upstream on the first time writing through to their downstream. But once it's in their local cache it would become possible to apply the smallest-first logic, wouldn't it?

This depends on how the proxy is configured to behave. One common pattern is to have a protocol terminating proxy talk to the client. Other component(s) sit behind this and they could be other parts of the system, tiers of caches or tiers of CDNs.

Even if the proxy does cache locally to memory or disk. Without infinite space, there will be some chance of cache eviction and a need to fetch from the upstream again.

Our scenarios are different ends of a broad spectrum, and there's a lot in between. Which is why getting prioritisation right is a hard nut to crack.

I am not sure it is a good idea to trust the server to decide what is more important. I can easily imagine ads taking higher priority than actual content, just look at the pop-ups that interrupt reading.

Browsers and protocol should start concentrating on how to secure users from the very sites they visit.

Prioritization works within a single HTTP/2 connection. Ads are generally served by a 3rd party, and while there are some limited ways of sharing HTTP/2 connections across origins, I don't think any ad servers offer such a close integration.

Besides, sites already have blunt tools they can use if they really wanted to force ads to load first. This feature is more for site developers who care about performance. Instead of tweaking the markup and adding hints to help browsers request resources in the right order, they can now set the priorities directly and precisely.

We've got a solution to this as well! It's interesting enough to get its own blog post: https://news.ycombinator.com/item?id=19910926