WICG/priority-hints

Questions following initial implementation

yoavweiss opened this issue · 8 comments

While working on https://chromium-review.googlesource.com/c/chromium/src/+/678216 a few questions came up:

  • I realized that we have no real way to map "before" and "after" the current browser priority levels. So, do we really need them? I'm not sure that they are actually required to resolve the use cases.
  • I used the priority levels in order to make a decision regarding very-short-term deference of resources so that preloaded resources won't get in the queue before critical resources. Thinking about this some more, it is something probably worth doing as the default regardless of explicit hints.
  • Do we need a way to further throttle resources? e.g. If I preload third party resources, in current scheme there's no way to prevent them from contending over bandwidth with the first party critical resources.

Thoughts?

While working on https://chromium-review.googlesource.com/c/chromium/src/+/678216

W00t. Great to see you experimenting already :)

I realized that we have no real way to map "before" and "after" the current browser priority levels. So, do we really need them? I'm not sure that they are actually required to resolve the use cases.

Yeah. I'm struggling to think of cases where the current priority levels would be insufficient for solving use cases documented in the README. I don't think we need to map to before/after the current levels. Will think about it some more.

Do we need a way to further throttle resources? e.g. If I preload third party resources, in current scheme there's no way to prevent them from contending over bandwidth with the first party critical resources.

I don't strongly feel we need a resource throttling algorithm for the V0.

Take the case of a third-party hosted hero video player: if a developer assigns a higher priority class to a set of third-party resources (scripts/resources for the player), my intuition would be that they would also set a lower priority to other resources on the first-party origin (top-level styles/images/js) to avoid such contention.

I may be giving folks too much credit there however :)

At BlinkOn, we briefly discussed leaving space for a UA to intervene (throttle) on behalf of the user when a developer made a call that might hamper performance. There may be other classes of interventions, like throttling, we could consider for the future.

The main use cases I seen for throttling when using preload are:

  1. First party resource which "gets ahead" of more critical resources when preloaded using a Link header.
  2. Third party resource which contends on bandwidth with first party critical resources when discovered early.

No. 1 could become the default behavior when non-critical priority resources are first discovered (so those requests don't go out before the initial chunk of HTML is done being processed in the preloader). It's a simple change, and IMO makes sense. Thoughts?

No. 2 Could also become the default behavior for non-critical third-party resources, where they are throttled until some point in the critical resources fetching (this is a bit more delicate, as I'm not sure what that point should actually be. Also we probably want to preconnect those hosts in the mean time)

Reflecting a little more, I think the default behavior for 1. makes sense.

The delicacy around 2. makes me wonder how much we should focus on it being a default for the V0. I'd be curious to hear what others think.

Awesome work on the proposal @yoavweiss

I realized that we have no real way to map "before" and "after" the current browser priority levels. So, do we really need them? I'm not sure that they are actually required to resolve the use cases.

Cant really think of a use case where this would be useful, IMO keeping things simple by having a strict subset of priority levels would solve most of the use cases.

Most of the times the need granular control on the execution order would only be needed for scripts and we could solve those using defer attribute.

Is there any update on this, or any way I could help out?

@ev1stensberg How much bandwidth might you have to help out? I'm working on the first draft of a ReSpec version of priority hints this month. Could use some assistance with code examples for the use cases :) see #18 for where I'm starting on this.

@addyosmani Got enough time 😆 Can help you with the code examples

Closing this. The new spec doesn't include execution or subresources and scheduling of the fetch of different priorities across different origins is currently a browser-level heuristic for the internal scheduling.