IMO, we should add defer async to the rest of the scripts too. I see no reason not to.

adding defer I can understand but adding async will make the script execute in parallel with HTML parsing that means while the scripts are executing, the DOM might not have been parsed and we need the DOM to be parsed before executing the script. Please correct me if I am wrong.

adding defer I can understand but adding async will make the script execute in parallel with HTML parsing that means while the scripts are executing, the DOM might not have been parsed and we need the DOM to be parsed before executing the script. Please correct me if I am wrong.

+1, I too think only defer is fine, async is not required it might cause conflict

Correct, the script will execute before the DOM is parsed.

However, the execution of the script only registers the listeners (.addEventListener()). The callback function that is registered with each listener will trigger only when the corresponding event fires.

If we take the following code:

The listener will be registered before the HTML parser is done, but the callback (everything within function () { ..} will run only when the "load" event fires. And the "load" event fires way after the DOM is parsed. Same applies for the DOMContentLoaded event.

thanks for the clarification!

Shall we do that in a separate issue? I'll open it if you are okay with that. Just so this PR and issue remain scoped to the UI flickering issue.

Let's merge this PR, and extend all others scripts in separate PR

I created an issue for the other scripts:

• Add async and/or defer attributes to site scripts #18045

@Zopsss Please let me know if there's anything else to do.

Sorry for the delay. Everything looks fine. Thanks a lot for detailed explanations!

This if-else is mandatory to prevent a race condition where the DOMContentLoaded event might fire before the listener is created. Taken straight out of the docs¹:

Sometimes your script may run after the DOMContentLoaded event has already fired. This typically happens when the script runs asynchronously. Common scenarios include: [...]

• A script that is included via <script async>.

[...] In these cases, you should check the document's readyState before adding a DOMContentLoaded listener, or your setup logic may not execute at all. [...]
Consider the following script file in isolation:

function doSomething() {
  console.info("DOM loaded");
}

if (document.readyState === "loading") {
  // Loading hasn't finished yet
  document.addEventListener("DOMContentLoaded", doSomething);
} else {
  // `DOMContentLoaded` has already fired
  doSomething();
}

The script can't enforce how it's included by the HTML. If it's included via <script async>, or it's dynamically injected, then by the time it executes, DOMContentLoaded has already fired. To ensure that doSomething() always runs when the script loads, we need to have two paths, one that immediately runs doSomething if the document is already loaded, and another that runs doSomething once the document is loaded.

This race condition can happen with the DOMContentLoaded event, but not with load²:

The load event is fired when the whole page has loaded, including all dependent resources such as stylesheets, scripts (including async, deferred, and module scripts), iframes,