Early PSA: Separate Defer Module Script Tasks
Helmut Januschka
Hey folks,
We’ve recently landed a fix on issue where multiple deferred scripts where all executing in the same task. That’s something developers have been complaining about, as a source of long tasks in sites that have many different deferred scripts from various sources.
The fix is behind the experimental SeparateDeferModuleScriptTasks flag at the moment and +Scott Haseley is planning to Finch it to see its impact on INP in the wild.
As far as we can tell, because current deferred scripts are running at a very high priority, the fix is barely web-exposed. rAF is the only JS-driven task that can now run in between those scripts, and even that is only when the scripts delay it by over a 100ms. For classic deferred scripts or external module scripts, rAF could already run between them in case of a network delay. Inline module scripts are the only ones where rAF could not run between the different scripts before, and now it can.
Given the above, and the amount of work it took us to actually find a scenario where this is WPT-testable, we don’t think there’s real compat risk with shipping this. At the same time, this will be behind a flag so we can roll it back quickly in case of surprises that we’d somehow miss during the Finch period.
There’s still an open question of whether the HTML spec needs to be changed, or if “spin the event loop” allows for the tasks to be queued. We’d appreciate opinions on that front.
Noam Rosenthal
>
> Hey folks,
>
> We’ve recently landed a fix on issue where multiple deferred scripts where all executing in the same task. That’s something developers have been complaining about, as a source of long tasks in sites that have many different deferred scripts from various sources.
> The fix is behind the experimental SeparateDeferModuleScriptTasks flag at the moment and +Scott Haseley is planning to Finch it to see its impact on INP in the wild.
https://chromium.googlesource.com/chromium/src/+/main/third_party/blink/renderer/platform/RuntimeEnabledFeatures.md#:~:text=If%20your%20feature%20could%20be%20reasonably%20expected%20to%20cause%20compat%20issues%2C%20please%20keep%20it%20marked%20no%20status%20or%20status%3A%22test%22%20%5B4%5D%2C
If your feature could be reasonably expected to cause compat issues,
please keep it marked no status or status:"test"
I think this can be reasonably expected to cause compat issues, though
I hope it doesn't!
> There’s still an open question of whether the HTML spec needs to be changed, or if “spin the event loop” allows for the tasks to be queued. We’d appreciate opinions on that front.
The conclusion so far is that both the old behavior and the new
behavior are spec-compliant.
Helmut Januschka
Yoav Weiss (@Shopify)
@nrose...@chromium.org - got you. should i do a follow up CL or revert and reland?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFmjHKS2d6NpkoQnFDh1zhYD%2BnVYPGVjOr0R%2BTX_we_J6R%3D62g%40mail.gmail.com.
Michal Mocny
Noam Rosenthal
On Fri, Sep 19, 2025 at 2:26 PM Helmut Januschka <hjanu...@gmail.com> wrote:@nrose...@chromium.org - got you. should i do a follow up CL or revert and reland?I believe a follow up is sufficient
Yoav Weiss (@Shopify)
RE "rAF is the only JS-driven task that can now run in between those scripts"Are new user input events the other example?
Indeed. But they are user-driven rather than JS driven so it's hard for developers to rely on their timing.
And isn't that somewhat the primary use case for doing this break up of the singular long task?
Indeed again :)
Yoav Weiss (@Shopify)
On Fri, Sep 19, 2025, 1:46 PM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:On Fri, Sep 19, 2025 at 2:26 PM Helmut Januschka <hjanu...@gmail.com> wrote:@nrose...@chromium.org - got you. should i do a follow up CL or revert and reland?I believe a follow up is sufficientAgreed!One think to look out for before we ship this is whether it regresses FCP/LCP for some sites.eg if the page relies on module scripts to load the LCP, having additional render frames in between scripts might slow it down.
Yeah, definitely something to measure as part of the Finch.