-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Module script dependencies and fetch priority #10276
Comments
See #8470 (review) and #8470 (comment). @pmeenan mentioned that in the spec discussion (presumably this means discussion in the Priority Hints spec, before the HTML upstreaming was started) that priority would not cascade down / be inherited by dependent resources. The why behind this is not obvious to me, so maybe Pat can link to some of the spec discussion he referred to and help us clarify this? |
It was a simplifying decision around scripts, iframes and modules that the At least in Chrome, "auto" for a module script dependency should already be high and you wouldn't be able to boost it anymore. It's less clear that you'd want dependencies to be lowered again after the main resource was loaded or what that would even mean (i.e. for a script, would every fetch from within the script get a forced priority change, what would break if that were the case). It's a bit clearer in the iFrame case for something like a video embed or chat widget (ignore for now that fetchpriority doesn't actually apply to iframes but consider the grouping). Just because you want the frame itself to load later doesn't mean you want it to load slowly once it has started. So, we decided that fetchpriority on the main resource would control when things started but would then get out of the way and if we had a case for more fine-grained control over grouped execution contexts that that would be something else solved at a different time (once the use case for it was clear). |
I think there's a difference here between "script A loads script B" (in which I agree we don't want to inherit priority automatically) and "script A statically imports script B" in which script A will not execute until script B is there. I think it makes sense to consider A & B the same resource in this case, as they are totally co-dependent. Aside: I missed the fact that module scripts don't get priority modifications in Chromium. That means that this doesn't matter in practice (in Chromium) when upgrading priority, but can definitely matter when downgrading it. |
Even in the downgrade case, because of the late discover of imports, it's not obvious that cascading the downgrade is the "right" thing to do. ExampleLet's say we have a page with a module script ...
<script type="module" src="a.js"></script>
<img src="1.jpg">
<img src="2.jpg">
... On the browser side, some simplifying assumptions for the purpose of the example (close enough to actual behavior):
Also assume we have a browser and server that honor prioritization:
Let's say that Default loading behaviorBy default, the order for the resources being loaded would be something like:
Adjusting with fetchpriorityBy default, ...
<script type="module" src="a.js" fetchpriority=low></script>
<img src="1.jpg" fetchpriority=high>
<img src="2.jpg">
... Priority does NOT cascadeIn the case where the priority for module scripts does not affect the import priorities,
It's not perfect, but it gets Priority cascadesIn the case where the priority for module scripts does affect the import priorities,
This delays the execution of BundlesIn the case of bundling the modules at build time,
ThoughtsNot cascading is the closest to "bundled" behavior and basically mimics the behavior of Fonts where late-discovery of resources that are needed by the thing they are loaded by are loaded at a high priority because they are needed now. The discovery changes a bit when it comes to import maps or preloads so I could see making a case for "fetchpriority=low on a module script where the imports are already in-flight does not modify the priority of the existing requests" so you could get the ordering directly from the import maps or preloads but I don't think it should be the default behavior. The other option would be to extend loading=lazy or something like that to module scripts of you want a situation where the imports all load at idle time. |
What is the issue with the HTML Standard?
According to descendant script fetch options, module script dependencies are fetched with an "auto" priority.
I'd love to understand the reasoning for this - given that the descendants are blocking the parent from executing, if the parent got its priority upgraded, shouldn't the same apply to these blocking dependencies?
In the inverse case, if the parent got its priority lowered, the dependencies are similarly of lower priority.
Is there a reason the descendants don't simply inherit the fetch priority from the parent?
^^ @domfarolino
The text was updated successfully, but these errors were encountered: