Intent to Experiment: Priority Hints

1066 views
Skip to first unread message

Dominic Farolino

unread,
Jan 19, 2019, 5:16:26 PM1/19/19
to blink-dev, Yoav Weiss, kenji...@chromium.org

Contact emails

domfa...@gmail.com, yo...@yoav.ws, kenji...@chromium.org


Spec

WICG spec: https://github.com/WICG/priority-hints

HTML Standard issue for discussion: https://github.com/whatwg/html/issues/3670


Summary

The intention of the Priority Hints API is to let developers signal to the browser how much a resource-fetching HTML element matters to the user experience. The browser may take this signal into consideration when prioritizing the request.


Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/65lfM2f0eeM


Goals for experimentation

The goal is to test potential resource loading speed-ups with Priority Hints, primarily by the use of:

  • <img src=... alt=... importance=high>, to allow developers to explicitly prioritize in-viewport images as high

  • <link rel=preload as=... importance=low>, to allow developers to down-prioritize certain preloads which may contend with other more important resources needed immediately

  • Potential <iframe> testing with other partners (for advertisements)

    • Though it should be noted that the effect of Priority Hints on an <iframe>’s subresources has not been decided upon yet, so no immediate testing could be done with this


The metrics used to measure potential resource loading speed-ups will be measured by partners using Priority Hints during the trial period. Given some recent studies in HTTP/2 prioritization on the server-side, one of our goals is to pair up with vendors that might enable us to test Priority Hints with a hosting provider that handles HTTP/2 priorities well, to see the full effects.


Experimental timeline

M73-M74.


Any risks when the experiment finishes?

There are no risks, as the only markup change required to use the feature is an HTML content attribute which will be ignored by browsers that do not support Priority Hints. The worst thing that could happen here is any potential speed-ups Priority Hints provides would go away in the gap between the experimentation deadline, and shipping.


Ongoing technical constraints

No.


Debuggability

Same as in I2I.


Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

Yes.


Link to entry on the feature dashboard

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


Kinuko Yasuda

unread,
Jan 21, 2019, 12:29:42 AM1/21/19
to Dominic Farolino, blink-dev, Yoav Weiss, Kenji Baheux
Non-owner LGTM, we've been poking around the feature in limited experimental cases, but being able to collect more data would give us a lot better insights about when this feature could be good or not.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4180fc62-eb42-4437-afbb-67472801c381%40chromium.org.

Addy Osmani

unread,
Jan 22, 2019, 1:06:29 AM1/22/19
to blink-dev, domfa...@gmail.com, yo...@yoav.ws, kenji...@chromium.org
Non-owner LGTM. As Kinuko allured to, most of our experiments using Priority Hints have focused on small applications. We're interested in data from the field on how Hints can help reduce network contention in medium to larger scale applications. Any and all feedback is welcome :)

Yoav Weiss

unread,
Jan 22, 2019, 1:31:15 PM1/22/19
to atakan...@gmail.com, blink-dev, Kenji Baheux
I'm (again) not signing off as I'm too close to the effort, but I'd like to express why I think this experiment is important.

Priority Hints is one of those features where it's hard to estimate if its theoretical benefits will actually translate into performance benefits in real-life scenarios, where those benefits depend on the webapp's loading patterns. The benefits also rely on server-side implementations to respect the priorities in a responsive manner.

Therefore, experimenting with the feature in the wild will give us initial results of how it behaves in real life. That will enable us to see what kind of performance improvements will the feature give us in practice, as well as enable us to see if the current API shape covers all the use-cases the feature aimed to resolve. 

On Tue, Jan 22, 2019 at 2:45 AM <atakan...@gmail.com> wrote:
This is good for feature I think. We need one code for all html/css/js files to load first or at the end. Specialy third party files...

20 Ocak 2019 Pazar 01:16:26 UTC+3 tarihinde Dominic Farolino yazdı:

atakan...@gmail.com

unread,
Jan 22, 2019, 4:01:54 PM1/22/19
to blink-dev, yo...@yoav.ws, kenji...@chromium.org
This is good for feature I think. We need one code for all html/css/js files to load first or at the end. Specialy third party files...

20 Ocak 2019 Pazar 01:16:26 UTC+3 tarihinde Dominic Farolino yazdı:

Contact emails

Rick Byers

unread,
Jan 22, 2019, 4:44:09 PM1/22/19
to Yoav Weiss, atakan...@gmail.com, blink-dev, Kenji Baheux
Sounds awesome!
LGTM

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

Yoav Weiss

unread,
Jan 24, 2019, 11:16:51 AM1/24/19
to Rick Byers, atakan aydın, blink-dev, Kenji Baheux
Thanks for reviewing!

The experiment is now enabled on M73. 
Note that due to partner feedback, Dominic added script support as well, to enable the use case of loading async scripts with high priority.
Reply all
Reply to author
Forward
0 new messages