Hi webkit-dev,

This is a request for Webkit's position on Priority Hints.
Draft Spec: https://wicg.github.io/priority-hints/
Explainer: https://github.com/WICG/priority-hints/blob/main/EXPLAINER.md

Priority Hints was explored in 2018 as part of the w3c web performance
working group 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 prioritization (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.


webkit-dev mailing list

Reply via email to