Subresource request prioritization of <iframe> and <script>
domfarolino opened this issue · 11 comments
Both <script> and <iframe> DOM elements can trigger a lot of resource requests. It's true we don't have a real processing model in this document, but we should still probably define here what effects the importance value given to a top-level <script> or <iframe> will have on their requested subresources. Note: this is different than the dependency graph request prioritization of a module script which is outside of the scope of this discussion.
Here are a few questions:
Should subresources be given the same importance value as their parent?
In other words, should every request made in the below example all have importance = low
// index.html
<iframe importance=low src=doc.html></iframe>
<script importance=low src=main.js></script>
// doc.html
<img src=https://image.here alt=image>
// main.js
fetch("https://domfarolino.com")
This definitely seems logical to me to get the most benefit out of the Priority Hints effort.
What if subresources have conflicting importance values?
In other words, what are the resolved importance values of all of the below requests:
// index.html
<iframe importance=low src=doc.html></iframe>
<script importance=low src=main.js></script>
// doc.html
<img importance=high src=https://image.here alt=image>
// main.js
fetch("https://domfarolino.com", {importance: high})
I'm not sure what the best call to make here is. In my opinion, the two best options are:
- Leave it up to implementations
- Ignore overridden subresource
importancevalues, they should just assume that of their parent
What about a script that adds an element to the DOM with a higher importance than the script itself?
<script importance=low src=main.js>
// main.js
let link = document.createElement('link');
link.importance = 'high';
link.......
.....
document.head.appendChild(link);
I'm not even sure if we could bully-down the added element's priority based on who added it to the DOM, but I don't think we should do that in this case. IMO I think it would make sense if the <link>'s ultimate importance was high here.
...more example? Thoughts?
I assume it would be good to specify this in the document so people can see how far-reaching and influential an importance value is on these types of elements.
Should subresources be given the same importance value as their parent?
The way I envisioned PR working is that subresources would automatically get the same importance as their parent, yes.
What if subresources have conflicting importance values?
I'm tempted to encourage overriding subresource importance values (because otherwise we can easily end up with third-parties/ads attempting to increase their priorities, contending with more critical main page requests)
We could attempt to define an algorithm that starts off using the same importance as the parent but does does respect subresource importance values once the main page has completed loading. This feels fragile and prone to falling apart once in-flight network requests are considered.
Perhaps we start off with overriding and see if there's vendor pushback (deferring to UA could be considered a fallback if there's too much contention).
What about a script that adds an element to the DOM with a higher importance than the script itself?
I have grave concerns with this being abused by third-parties. I don't have a good answer for it just yet but will noodle on the problem for a bit.
Should subresources be given the same importance value as their parent?
I agree with Addy. Especially, in the iframe case.
What if subresources have conflicting importance values?
Same here, I think the parent's importance takes precedence. I think we should let the developers decide to remove the ceiling when they think it's right by updating / removing the importance on the parent.
What about a script that adds an element to the DOM with a higher importance than the script itself?
Also concerned about this. But there are already "Loading take-over" issues with third parties in general. I'm hoping we can find a generic solution that gives back control to the publisher. In some sense, Service Worker provides some of that control by giving the website owner the final say for fetch events.
That all sounds good to me. And yeah I'm really not sure how we could "defend" against the inserted things though it is still an interesting point. Thanks for all the thoughts on this!
I generally agree with Addy and Kenji, i.e. +1 to start off with overriding and see if we have push backs (seems better than doing the other way around). Capping or adjusting the priority at the parent resource's importance/priority feels saner. While just capping everything may squash the priorities into one or two and UX within low-importance iframes may become suboptimal-- where UA could probably do smarter thing though.
What about a script that adds an element to the DOM with a higher importance than the script itself?
This exists today, e.g. low-priority async script can insert a preload, which triggers a high-priority request. It feels it's possible to cap the priority/importance there too but maybe that can be split into a separate discussion.
@domfarolino from the examples it seems like you need to patch the HTML Standard too to define the new attribute and some of the surrounding infrastructure. And you want to consider whether this should apply to SVG elements as well. E.g., we try to treat svg:image and html:img more or less identical.
As a general comment, I expect you'll need to loop in more people to make this successful as this has come up quite a few times already in Fetch and HTML, but it's never quite clear who is in the best place to prioritize resources.
Sounds good, thanks!
@annevk Indeed, we've talked a bit with Domenic about adding this to HTML and Fetch (for fetch()), and will be filing some things soon. Good point regarding SVG elements; I imagine that would be a good idea though we'll likely need to look at it a bit more.
We'll be looping more people in, probably implementers, over the next little while over issues on those previously mentioned specs; in the mean time how do you feel about this sort of "subresource priority clamping" discussed here in which the parent element's importance value can affect that of its subresources, does that seem like a good thing here?
Yeah, for <iframe> that seems reasonable.
Given the latest discussion over at whatwg/html#3670, it seems that we aren't going to be moving forward with the trickle-down "subresource" prioritization from requests made within a <script importance=...> due consistency and current JS engine habits, however we can still move forward with <iframe importance> subresource prioritization as discussed.
After reviewing the discussion on whatwg/html#3670 (sorry for not seeing the notification for it sooner), I support us moving forward with <iframe importance> and punting on trickle-down prioritization of subresources for <script>.
I feel like there's probably further discussion to be had about how we handle subframes looking at the comment from Boris in whatwg/html#3670 (comment)
I'd push in the opposite direction (and for what Chrome actually has implemented now) and not have the priority hit cascade beyond the initial resource fetch for any elements (iFrame or script). It is easy to reason about the initial resource and priority hints are scoped just to network fetching, not execution.
Something like a video embed in an iFrame that is a low priority should schedule the iFrame itself to load later than it might otherwise but once the user is interacting with the video you really wouldn't want to have the stream inheriting a low priority. The long-term footgun possibility is very high (and the implementation complexity is also fairly extreme).
It's also the source of most pushback on the issue on the HTML spec.