[lucaspardue]

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.

[jacques_chester]

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?

[lucaspardue]

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.