Intent to Experiment: Priority Hints

[Patrick Meenan]

Contact emails

ad...@chromium.org, domfa...@gmail.com, kenji...@chromium.org, pme...@chromium.org

Explainer

https://github.com/WICG/priority-hints/blob/main/EXPLAINER.md

Specification

https://wicg.github.io/priority-hints/

Summary

Priority Hints provide developers a way to indicate a resource's relative importance to the browser, allowing more control over the order resources are loaded. Many factors influence a resource's priority in browsers. These include type, visibility, and preload status of a resource. Priority Hints introduces a developer-set "importance" attribute allowing developers to influence the computed priority of a resource. Supported importance values are auto, low, and high.

Blink component

Blink>Loader

Search tags

priority-hints, priority hints

TAG review

TAG review status

Pending

Risks

Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

Web developers: Strongly positive

Goals for experimentation

The goal is to re-start the origin trial experiment for Priority Hints with a focus on some specific use cases that have generated significant developer interest: * Boost the priority of the LCP image for a page by specifying importance="high" on the image element, causing LCP to happen sooner. * Increase the priority of async scripts using better semantics than the current hack that is commonly used (inserting a link preload for the async script) * Decreasing the priority of late-body scripts to allow for better sequencing with images. * Decreasing the priority of CSS to allow for sequencing with parser-blocking scripts. * Allow for varying priorities of javascript-initiated fetches. The bulk of the experiment will be focused on making sure the API surface meets developers needs and works as expected.

The previous experiment was run 2 years ago before the recent focus on core web vitals and LCP in particular and did not generate as much developer interest as there is now. There were also prioritization issues with preload that are fixed in 95 that made it difficult to experiment with for the script case.

There is pretty significant demand from developers for the knobs that Priority Hints provide, particularly for improving LCP.

Ongoing technical constraints

None

Debuggability

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

No

Flag name

Requires code in //chrome?

False

Tracking bug

https://crbug.com/821464

Estimated milestones

OriginTrial desktop last	101
OriginTrial desktop first	96
OriginTrial android last	101
OriginTrial android first	96

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5273474901737472

Links to previous Intent discussions

Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/jpeSdM897Xw/m/CY6tothSDgAJ

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

Thanks for working on this!!

On Tue, Sep 14, 2021 at 5:38 PM Patrick Meenan <pme...@chromium.org> wrote:

Contact emails

ad...@chromium.org, domfa...@gmail.com, kenji...@chromium.org, pme...@chromium.org

Explainer

https://github.com/WICG/priority-hints/blob/main/EXPLAINER.md

Specification

https://wicg.github.io/priority-hints/

Summary

Priority Hints provide developers a way to indicate a resource's relative importance to the browser, allowing more control over the order resources are loaded. Many factors influence a resource's priority in browsers. These include type, visibility, and preload status of a resource. Priority Hints introduces a developer-set "importance" attribute allowing developers to influence the computed priority of a resource. Supported importance values are auto, low, and high.

Blink component

Blink>Loader

Search tags

priority-hints, priority hints

TAG review

It might be good to spin up a TAG review.

 

TAG review status

Pending

Risks

Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

Did you reach out? https://bit.ly/blink-signals 

Web developers: Strongly positive

Any links?

Any particular reason you want to run the OT for 6 milestones?  It may be better to start with 4 and extend as needed..

Do you have partners lined up to experiment?

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5273474901737472

Links to previous Intent discussions

Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/jpeSdM897Xw/m/CY6tothSDgAJ

This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w7f0siM7vz0-e2F7_8QfMEH_ZaG-8ga27_4vFp4493gbA%40mail.gmail.com.

[Patrick Meenan]

On Wed, Sep 15, 2021 at 3:49 AM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks for working on this!!

On Tue, Sep 14, 2021 at 5:38 PM Patrick Meenan <pme...@chromium.org> wrote:

TAG review

It might be good to spin up a TAG review.

Thanks. I'll start working on that now.

 

 Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

Did you reach out? https://bit.ly/blink-signals 

I'll take it back to the W3C web perf working group and see what they have to say.  I'm not expecting a lot of browser interest (except maybe Edge) because Chromium is the only engine that uses the 2-step loading phase where hints can move resources back and forth between the render-blocking and "everything else" phases (and we don't all necessarily agree on incremental rendering being a good thing).  It has been 2 years though so it's good to gauge interest again as things have changed a lot since the initial pass through.

 

Web developers: Strongly positive

Any links?

This is fairly representative: https://twitter.com/csswizardry/status/1050717710525509633

These days it is usually more in the form of "how can I get my LCP image to load sooner" questions on stack overflow and twitter (happy to link to a few of them). Most devs don't call out Priority Hints specifically, it's usually in the form of a script loading sooner than they expect or an image loading later than they would like with no way to change it. Priority Hints is just the transport by which we allow them to make those adjustments (in addition to letting us unwind the practice of using preload to boost the priority of async scripts).

There are also some internal discussions for a team that uses fetch on HTTP/3 where they would like to be able to have lower-priority background requests in flight that don't interfere with the user-facing API calls.

 

 

Estimated milestones

OriginTrial desktop last	101
OriginTrial desktop first	96
OriginTrial android last	101
OriginTrial android first	96

Any particular reason you want to run the OT for 6 milestones?  It may be better to start with 4 and extend as needed..

Do you have partners lined up to experiment?

Moving to a 4-week release cycle, calendar-wise it's about the same. Optimally we will be able to make the ship decision within a couple of weeks of hitting stable but in case the process takes longer than expected I was erring on the side of a bit of buffer so it doesn't get disabled from under a site as we work to ship. There's also the potential for some delayed feedback cycles as the LCP impacts and side-effects will be measured through RUM tools and search console's 28-day rolling average on CrUX data.

Is there a problem with planning for a bit of a buffer and ending sooner rather than planning sooner then scrambling to extend?

 

Thanks,

-Pat

[Yoav Weiss]

On Wed, Sep 15, 2021 at 9:40 PM Patrick Meenan <pme...@chromium.org> wrote:

On Wed, Sep 15, 2021 at 3:49 AM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks for working on this!!

On Tue, Sep 14, 2021 at 5:38 PM Patrick Meenan <pme...@chromium.org> wrote:

TAG review

It might be good to spin up a TAG review.

Thanks. I'll start working on that now.

 

 Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

Did you reach out? https://bit.ly/blink-signals 

I'll take it back to the W3C web perf working group and see what they have to say.  I'm not expecting a lot of browser interest (except maybe Edge) because Chromium is the only engine that uses the 2-step loading phase where hints can move resources back and forth between the render-blocking and "everything else" phases (and we don't all necessarily agree on incremental rendering being a good thing).  It has been 2 years though so it's good to gauge interest again as things have changed a lot since the initial pass through.

That makes perfect sense. It's also not a replacement for asking for explicit signals. That's not a blocker for the OT, but would be a blocker for shipping later on.

 

 

Web developers: Strongly positive

Any links?

This is fairly representative: https://twitter.com/csswizardry/status/1050717710525509633

These days it is usually more in the form of "how can I get my LCP image to load sooner" questions on stack overflow and twitter (happy to link to a few of them). Most devs don't call out Priority Hints specifically, it's usually in the form of a script loading sooner than they expect or an image loading later than they would like with no way to change it. Priority Hints is just the transport by which we allow them to make those adjustments (in addition to letting us unwind the practice of using preload to boost the priority of async scripts).

There are also some internal discussions for a team that uses fetch on HTTP/3 where they would like to be able to have lower-priority background requests in flight that don't interfere with the user-facing API calls.

 

 

Estimated milestones

OriginTrial desktop last	101
OriginTrial desktop first	96
OriginTrial android last	101
OriginTrial android first	96

Any particular reason you want to run the OT for 6 milestones?  It may be better to start with 4 and extend as needed..

Do you have partners lined up to experiment?

Moving to a 4-week release cycle, calendar-wise it's about the same. Optimally we will be able to make the ship decision within a couple of weeks of hitting stable but in case the process takes longer than expected I was erring on the side of a bit of buffer so it doesn't get disabled from under a site as we work to ship. There's also the potential for some delayed feedback cycles as the LCP impacts and side-effects will be measured through RUM tools and search console's 28-day rolling average on CrUX data.

Is there a problem with planning for a bit of a buffer and ending sooner rather than planning sooner then scrambling to extend?

Before the move to 4 weeks per milestone, a typical was run for 2-3 milestones, which is equivalent to 3-4.5 nowadays. Let's settle on 5 milestones? :)

Extending the trial if needed shouldn't take more than sending an intent to extend, ideally with learnings so far.

 

Thanks,

-Pat

[Patrick Meenan]

SGTM. I'd like to ship as soon as possible anyway and have no interest in dragging it out.  

[Yoav Weiss]

LGTM to experiment M96-M100 (inclusive).

[Yoav Weiss]

Given Mike's reply on the other thread, providing a link to our actual guidelines on OT length, I'm changing my LGTM to M96-M99(inclusive).

Let us know if this is insufficient for some reason.

[Patrick Meenan]

M96-M99 works great, thanks all.