Priority Hints #606
Comments
|
These all sound like reasonable use-cases to me. @Bas-moz any thoughts? |
|
Agreed. This is reasonable. @smaug---- what do you think, you have more expertise around our page load scheduling capabilities here? |
|
I've reviewed the specification. It is clearly a work in progress, and I've provided some feedback. That said, the basic idea is sound and worth investigating further. It's simple enough that it might work even, at least from how it interacts with networking. |
|
The spec is obviously very initial draft so it needs quite a bit work before implementations should ship, but yes, this idea has been around for over a decade. Internally Gecko has various ways to prioritize requests, and quite a few heuristics like possibly-visible-images or handling XHR/fetch in reaction to user input. Anyhow, the idea sounds reasonable. |
|
FWIW, the TAG review just completed and I'm landing the last bits of the HTML spec processing model changes this week (just plumbing the attribute through to the underlying fetch). Are there any remaining concerns with the spec? It has been in Origin Trial with Chrome for a few months now and will likely be going for intent-to-ship in the next week or so. |
|
The issues mentioned in whatwg/html#7150 haven't been resolved. I'd really prefer to be more precise with the naming. |
|
@smaug---- the name change has landed. Do you know of any other concerns with the feature/spec? Would it be possible to get an official position on it from Mozilla? |
|
the DOM side of it looks now quite reasonable. |
|
That stuff is mostly fine (though I might discourage HTTP/2 priority signaling rather than encouraging it as this does, it's fine). Thanks for looking into this @smaug----, I'll put up a pull request. |
|
One last thing for @pmeenan: please try to find a home for this work that isn't WICG. https://www.w3.org/webperf/ seems like a good candidate. |
|
@martinthomson This work was from the web performance working group. @yoavweiss, is there something we need to do to associate the spec better? Eventually most of it will move into html/fetch once there are 2 implementations. |
|
Why is this in WICG then rather than webperf? |
|
It's in WICG as this work is still in incubation, and we didn't necessarily have 2 interested implementers. (Or even 1, in the lengthy period where we struggled to prove benefits, before Pat took over the work) The WG (very briefly) discussed adoption of this at TPAC, but Priority-Hints wasn't top-priority (pun not intended) for adoption at the time. If there's interest from Mozilla, we can definitely push for WebPerfWG adoption, although, given that most of the spec's processing model is HTML and Fetch monkey-patching, direct integration would probably be better. (as @pmeenan said above) /cc @bdekoz |
* Priority hints are worth more work Closes #606. * the trailing slash is important Co-authored-by: Anne van Kesteren <annevk@annevk.nl> Co-authored-by: Anne van Kesteren <annevk@annevk.nl>
|
I'd expect the proposal to be integrated somehow to the HTML and fetch specs. |
* Priority hints are worth more work Closes mozilla#606. * the trailing slash is important Co-authored-by: Anne van Kesteren <annevk@annevk.nl> Co-authored-by: Anne van Kesteren <annevk@annevk.nl>
Request for Mozilla Position on an Emerging Web Specification
Other information
Priority Hints was explored in 2018 in #25 but went stale. The work has re-started now that there are cleaner use cases and the scope has been reduced to only reflect the importance of the fetch for the initial resource referenced by an element (rather than cascading to all fetches within a frame or triggered by a given script).
Chrome has been running a field trial that started in 96 and early feedback is very positive and the plan is to push forward for a launch (any feedback on keeping "importance" or finding something more fetch-specific on the linked whatwg issue above would be appreciated).
The prioritization changes under the cover as a result of developer hinting can be applied both to internal browser fetch ordering as well as plumbed through to protocol-level prioritization for multiplexed protocols that support priotitization (HTTP/2 and HTTP/3 currently).
Use Cases
There are 3 concrete use-cases that have emerged that are current developer pain points that Priority Hints provides a relatively clean solution for with minimal effort on the developer's part.
Signaling Important Images
Identifying which images are important in markup gives a parse-time signal to the browser for ordering the image fetches. Chromium already has logic that boosts the priority of visible images in the viewport but that information is only available after styles have been applied and layout has been performed which is relatively late in the lifecycle of fetching resources for the page.
We have seen early gains in the 20-40% range for Largest Contentful Paint for sites in the origin trial where they can benefit from signaling of important images (Content pages with a main hero image and product detail pages for e-commerce sites are easy wins).
Differentiating API fetches
Script using the fetch API to both react to user input (like with autocomplete suggestions based on typing) and performing background bulk fetches benefits from being able to differentiate the priorities of the fetches. In this case, it works best if the transport protocol and origin all support prioritization but it provides application-level control to make the API calls more responsive than is otherwise possible.
Signaling the priority of async scripts
Async (and defer) scripts don't block tree-building so Chromium usually assigns them a lower priority. For some sites, the core framework and application logic are all loaded through async scripts and the lower priority can harm performance. There is a chromium-specific hack that relies on preloading the same script to get it to load with a higher priority. It would be a lot cleaner to signal it directly.
The text was updated successfully, but these errors were encountered: