asyncbehavior is not necessarily desired at all, here I'll try to explain why.
first of all: why script asyncBefore talking badly about this attribute, it's necessary to understand reasons behind.
asyncattribute aim is to not block network traffic.
deferred, where the order of scripts is preserved and the fact scripts will be parsed and executed before the
DOMContentLoadedevent would be regularly fired,
asyncscripts download and parse might occur at any time before or after the
DOMContentLoadedas well as the
onloadevent have been already fired.
<script async="shenanigans">Yes, if your library, framework, utility, entire Web App, relies for some reason to the
DOMContentLoadedevent listener, or even the classic
window.onloadevent, in order to initialize anything, such attribute will not guarantee that behavior at all: it's the other way round!
If the script tag is on top of the head of your page, the only place where defer or async make sense in order to not block the download of anything else in the page, it might be executed while the document is still donwloading as well as after everything else, in terms of DOM, has been interpreted already.
This situation is the most common one and not the less probable as you might think, 'cause the moment your script tag is interpreted, is the moment the browser knows already the content of the page.
From that point, to trigger a
DOMContentLoadedevent takes really nothing, milliseconds speaking.
If your script add that listener after, your script will never be triggered.
fixing the DOMContentLoadedLong time ago,
DOMContentLoadedin Firefox was the revolution for scripting initialization ... today this event looks ugly and unreliable, with its capital letters in the event type description, its past in the verb form compared with
loadwhich is not
loadedindeed, and at the same time is the most used event ever for anything that would like to operate before the user.
In this universal common case, it's ridiculous that such event, happened in the past as
Loadedwould suggest, will never trigger again in the
documentunless somebody manually tries to do so, screwing all libraries, frameworks, or application logic, that forgot to
removeEventListeneronce such event used for initialization has been fired ... you know what I mean?
Once For All: Fixed!This script has no license on purpose ... I don't really care if you remember me once you used this script on top of your page and inline, I really don't want you to even think about this post once you can sleep well thinking the
DOMContentLoadedevent triggered your initialization script ... really, just use this script for reliability sake and forget about problems related to asynchronously loaded scripts and libraries.
Anything that will trust such event, will be triggered ... and yes, all CSP can be used as well without problems so ... no excuses, just enjoy!