-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Consider adding blocking=render
for dynamic import()
#7976
Comments
The usage could be something like: <script type=module async blocking=render>
if (someCondition) {
const { foo } = await import('something.js', {blocking: 'render'});
// do something with foo
}
</script> |
I think this is a good idea. Some minor concerns:
|
For classic scripts, you can do this: <script>
"use strict";
if (someCondition) {
const scriptEl = document.createElement('script');
scriptEl.src = 'something.js';
scriptEl.blocking = 'render';
document.head.append(scriptEl);
}
</script> Good point about the API shape. Separate booleans for each thing might indeed be better. |
I think there's a general issue of how to create a chain of render-blocking resources. The current HTML spec allowing adding new render-blocking requests only if In w3c/csswg-drafts#7271, we have the same issue for font faces, and the current technical choice is to make it block the For dynamic |
It does not in the spec. Per #5824 implementations don't quite match the spec, so we might have some flexibility. But, what is the connection between the load event and render-blocking? I thought the load event would be unrelated. |
Sorry I wasn't precise enough. By "making it block the load event", I mean making it a critical subresource, so that it must be loaded (and evaluated if it's an imported module) before we perform the unblock rendering step. |
Oh, I see. There is no notion of critical subresource for script elements. We just unblock rendering for them after they run. We don't wait for any fetches they initiate, including those by mechanisms such as |
I think that should be changed so that new render-blocking requests can be added if there are currently unresolved render-blocking requests, regardless of whether |
We can do this specially for "secondary" requests (requests as a subresource of some element; not sure if we have a term for that). We can't do it for HTML elements because it will otherwise widely affect the FCP of current pages. |
OK, I can see that render-blocking declarative markup should be in |
As far as the TC39 side: I'm happy to help thread this through there if changes are needed. We already have import assertions, and this could be another category of key/value pairs analogous to that. With what's slated for JS, I believe it would already be possible for HTML to support syntax like |
In this Twitter thread about obsoleting
document.write()
(#7977) @matthewp pointed out that it's the only way to include conditional script dependencies that block the first paint. @domenic said thatimport()
creates a new module graph and so will not block rendering even if the<script>
hadblocking=render
.Possible ways to address this:
blocking=render
toimport()
e.g. as an options bag in a second argumentimport('something.js', {blocking: 'render'})
. Issue: how to check for support?blocking=render
to<link rel=modulepreload>
and specify that it should block rendering until the corresponding module is fully loaded and executed, not just fetched. (See Behavior ofblocking
attribute on apreload
link #7896.) Less ergonomic than the above for the conditional dependency use case, though.cc @xiaochengh @whatwg/modules
The text was updated successfully, but these errors were encountered: