Intervention: Throttle Loading in background

[toyoshim]

The idea is to limit the number of in-flight resource loading requests in background tabs or frames.

Chrome is experimenting with this idea on m61+.

Rough algorithm

• manage the in-flight request number per-frame basis
• if the in-flight requests reaches the limit, and new resource request is needed, the request is pushed into a pending list.
• if the frame gets to be in foreground, or in-flight request finishes, search the pending list, and issue new requests if the limit allows.

I'm exploring the best limit number for the main frame, and subframes respectively.

33 and #59 is related, and #59 would overrides this throttling behavior after the N mins

/cc @skyostil @altimin @spanicker

[bzbarsky]

It's not clear to me why this is an intervention, in the sense of "spec violation that improves things". This behavior is allowed already by existing specs.

[toyoshim]

Oops. That's right. I just thought it would help to share this because #59 's implementation depends on this. But you are right, this won't be a spec violation.

I may keep this issue open if this is still useful or worth sharing here. But if this is not a right place, just closing now is fine.

Thanks!

[ojanvafai]

It fits under the broader category of "change from long-standing behavior that web developers might be affected by." Whether specs allow it or not doesn't seem like the critical distinction to me.

But, I agree this is borderline.

[domenic]

As Boris says, this is already allowed by specs. Similar to https://github.com/WICG/interventions/issues/59#issuecomment-1101570925, we can work on speccing this if we have some evidence sites have started to depend on it, but in the meantime we'll lean on the fact that Fetch does not mandate any particular connection speed, and close this issue.