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. Thanks, -Pat