Would using defer instead of async fix this issue? The latter allows the page to continue parsing, but will still run as soon as it's loaded (possibly before the rest of the page is parsed). The latter always waits until the page is fully loaded before running.
I would recommend not doing that. The script tag is always bound to the load event. If the payload is huge the load event will wait for download. The async attribute merely tells the browser to execute the script contents asynchronously if properly supported and if fetched as a file from a src attribute.
A more stable approach is to put the code within a timer. This covers all use cases and is universally supported since nearly forever. Example:
let myCode = function () {};
setTimeout(myCode, 1);
Or
setTimeout(function () {}, 1);
Either way you are still stuck with network resolution of the script tag contents.
Assuming apps composed of light weight micro-libs I tend to find apps:
1) Miss taking advantage of browser capability to parallelize downloads, leading to lost real time in most browsing contexts.
2) Make it difficult if not practically impossible to leverage before domready cycles in the event loop.
Is it stable to detatch from the load event in the case script is not the initiatitor? Yes, unless one can reasonably expect document body to close (no more writes) at some real time after external downloads complete. But that potential pitfall, in any case, can be controlled with a deferred bound to the domready event.
What I have witnessed, however, is the browser tends to do a better job optimizing for scripts loaded over HTTPS in a way fetch cannot when controlled by the implementation.
This happens when an `async` script tag is encountered on a page programmatically fetching external assets. Not shown is the usefulness of Fetch Injection where control flow of script execution is concerned. But the blocking is not ideal in any case.
