yoavweiss
commented
6 years ago While this is very valuable, I (and I believe @yoavweiss) think that Priority Hints would actually be a good step to getting us there, and is not a blocker so much as a catalyst to that conversation (which there has been some, albeit not tons, of talk around). For example, by talk about how importance=high async scripts should be prioritized higher than importance=low async scripts, we're already making relative comparisons that the Fetch Standard does not yet talk about.
To expand on that point, current browser priorities are based on heuristics that are trying to guess the importance of resources based on unrelated attributes or the location of resources. A few examples from Chromium's priority logic:
- An async script (which means the script should not block HTML parsing) is assumed to be a low priority script.
- A bottom-of-the-page script (which may be there only to avoid blocking HTML parsing above it) is again assumed to be of lower priority.
- An out-of-viewport image is assumed to be low priority, even if it may be popped into the viewport (using JS) at an early stage, and therefore critical for the user experience.
All this to say that today's browsers work with what they got, but there's no way for devs to actually communicate intent as far as resource priorities go. Priority Hints enable that, and their adoption can help browsers to stop relying on heuristics, enabling them to converge on prioritization logic in the future.
domfarolino
addyosmani
At the Web Perf WG call today, it seemed that one of @toddreifsteck's more prominent hesitations revolved around the notion that Priority Hints might be trying to shift priorities among the many and different types (destinations, really) of resources. For example, a concern would have been "Well would a high importance image get prioritized higher than a low importance CSS file? And what if it did in Chrome but not Edge? etc." This sounded a bit like the original intent of Priority Hints (I recall group names and https://github.com/WICG/priority-hints/issues/7#issuecomment-331070080, which seems solved by specifying and emphasizing relative importance). I think a breakthrough we had in the conversation was when we mentioned that the prioritization of resources should be relative between types/destinations. For example, no matter what prioritization scheme might be used in Edge vs Chrome vs FF vs Safari, low-importance images should be prioritized lower than other non-low-importance images. The same goes for scripts, fetch()es, etc. Modifying the priority of a request relative to other requests of the same type definitely seems like something we'd like to make clear(er).
Assigning this to Addy right now as he's been digging around the spec quite a bit lately, but happy to pick this up if needbe after some more implementation work.
(aside from the main point of this issue:)
Another very reasonable hesitation we got revolved around the fact that it might be helpful to fully specify exactly how a resource gets prioritized, and some of the surrounding infrastructure, values, and logic so we could have this work dependably between the different implementations. While this is very valuable, I (and I believe @yoavweiss) think that Priority Hints would actually be a good step to getting us there, and is not a blocker so much as a catalyst to that conversation (which there has been some, albeit not tons, of talk around). For example, by talk about how
importance=highasync scripts should be prioritized higher thanimportance=lowasync scripts, we're already making relative comparisons that the Fetch Standard does not yet talk about.