Address the scheduler use-case

[yoavweiss]

It seems like LinkedIn added a scheduler to Ember in order to avoid low-priority resources from contending on bandwidth with high-priority ones.

To quote their blog post:
"The second library we made available was a scheduler. Many teams had what they considered to be less important content, even within the viewport, that could be deferred until the initial view was fully interactive. They had been employing various hacks, like timeouts, that were set to be longer than what they thought was the longest reasonable load time. However, in some cases the deferred content was interfering with the initial render and causing re-renders as it was injected into the DOM. So we created a scheduler for a logical queuing of deferred content—this was content that was guaranteed to load after the initial render was complete."

[domfarolino]

I agree addressing this as a use-case sounds good, but I'm curious as to what way we might be able to say about it? I assume we don't want to say that certain importance values will ensure requests always load after the initial render, as this is a little firm and normative; alternatively we could mention that assigning certain elements a low importance aids the browser in not sending the "unimportant" request before higher-priority potentially later-discovered requests so that truly important content gets bandwidth dibs.

This sounds pretty similar to https://wicg.github.io/priority-hints/#avoidbandwidthcontentioninmultipleoriginscenarios though I guess.

[domfarolino]

I guess the best we can do here, since specific prioritization and even painting stuff isn't really spec'ed in the HTML Standard, is "encourage" UAs to do some sort of queueing of low-priority requests maybe? We could at a high-level define a low-priority request queue whose requests we don't:

• Open TCP connections for on HTTP/1.1
• Multiplex with other connections on H/2

Until some maybe higher ones are sent out/completed? Not sure...

[annevk]

There's no kind of ordering at all. As such this would require a completely new proposal. Therefore I suggest this is closed as no work happened in the last four years and this repository is close to being obsolete.