Intent to Experiment: Priority Hints

153 views
Skip to first unread message

Patrick Meenan

unread,
Sep 14, 2021, 11:38:43 AMSep 14
to blink-dev

Contact emails

ad...@chromium.orgdomfa...@gmail.comkenji...@chromium.orgpme...@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-hintspriority 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 last101
OriginTrial desktop first96
OriginTrial android last101
OriginTrial android first96


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

unread,
Sep 15, 2021, 3:49:21 AMSep 15
to Patrick Meenan, blink-dev
Thanks for working on this!!

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

Contact emails

ad...@chromium.orgdomfa...@gmail.comkenji...@chromium.orgpme...@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-hintspriority 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

unread,
Sep 15, 2021, 3:40:17 PMSep 15
to Yoav Weiss, blink-dev
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?


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 last101
OriginTrial desktop first96
OriginTrial android last101
OriginTrial android first96


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

unread,
Sep 15, 2021, 4:16:46 PMSep 15
to Patrick Meenan, blink-dev
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?


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 last101
OriginTrial desktop first96
OriginTrial android last101
OriginTrial android first96


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

unread,
Sep 15, 2021, 4:39:07 PMSep 15
to Yoav Weiss, blink-dev
SGTM. I'd like to ship as soon as possible anyway and have no interest in dragging it out.  

Yoav Weiss

unread,
Sep 16, 2021, 2:27:56 AMSep 16
to Patrick Meenan, blink-dev
LGTM to experiment M96-M100 (inclusive).

Yoav Weiss

unread,
Sep 16, 2021, 3:58:25 AMSep 16
to blink-dev, Yoav Weiss, blink-dev, Patrick Meenan, Mike West
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

unread,
Sep 16, 2021, 11:02:57 AMSep 16
to Yoav Weiss, blink-dev, Mike West
M96-M99 works great, thanks all.
Reply all
Reply to author
Forward
0 new messages