Single on async vs defer on <script>

async and defer both make an external script download in parallel with HTML parsing. They differ in when the script runs and in whether several scripts keep their order.

Plain <script src> for comparison. With neither attribute, the script is fetched and evaluated immediately, and parsing is blocked until both are done. The spec says so: "If neither attribute is present, then the script is fetched and evaluated immediately, blocking parsing until these are both complete." (https://html.spec.whatwg.org/multipage/scripting.html)

async (external classic script)

• Parsing: The script is fetched in parallel with parsing. It is then "evaluated as soon as it is available (potentially before parsing completes)" (https://html.spec.whatwg.org/multipage/scripting.html). If it arrives mid-parse, it pauses the parser while it runs. MDN adds that execution "blocks the page from rendering" until the script finishes (https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script).
• Relation to DOMContentLoaded: There is no fixed relationship. The script can run before or after the event, and DOMContentLoaded does not wait for it. MDN says the event "doesn't wait for other things like images, subframes, and async scripts to finish loading" (https://developer.mozilla.org/en-US/docs/Web/API/Document/DOMContentLoaded_event). That page also has a note saying DOMContentLoaded fires "before the execution of scripts with async". That is a generalisation. The spec's "potentially before parsing completes" means a fast async script can run earlier. A script that must work either way should check document.readyState, as MDN's example does.
• Order: There is no guarantee. MDN says "You get no guarantee that scripts will run in any specific order", and that with three async scripts you can't assume jQuery loads first (https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script). In the spec's processing model, each async script goes into a "set" of scripts that execute as soon as possible, and runs when its own fetch is ready.

defer (external classic script)

• Parsing: The script is "fetched in parallel and evaluated when the page has finished parsing" (https://html.spec.whatwg.org/multipage/scripting.html).
• Relation to DOMContentLoaded: Deferred scripts run after parsing finishes and before DOMContentLoaded. MDN says the attribute means the script runs "after the document has been parsed, but before firing DOMContentLoaded event". It also says deferred scripts "will prevent the DOMContentLoaded event from firing until the script has loaded and finished evaluating" (https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script). While they run, document.readyState is "interactive" (https://developer.mozilla.org/en-US/docs/Web/API/Document/DOMContentLoaded_event).
• Order: Deferred scripts run in document order. MDN says "Scripts with the defer attribute will execute in the order in which they appear in the document". The spec's mechanism is that each parser-inserted deferred script is appended to a "list of scripts that will execute when the document has finished parsing", and the parser runs them from that list (https://html.spec.whatwg.org/multipage/scripting.html).
• Both attributes together: If both are present, async wins. MDN says the element "will act as if only the async attribute is specified". The spec permits writing both so that legacy browsers that only know defer fall back to deferring instead of blocking.

Inline scripts

• Classic inline scripts: async and defer do nothing. MDN warns they "must not be used if the src attribute is absent" and "would have no effect". The spec's algorithm agrees. An inline classic script has no src, so it is marked ready at once. Unless a style sheet is blocking scripts, it is then run immediately ("immediately execute the script element el"), during parsing. MDN also notes that inline scripts without type="module" are executed immediately before the browser continues parsing.
• Inline module scripts: These are the exception. In the spec's algorithm, the async-or-deferred handling applies to "el's type is 'classic' and el has a src attribute, or el's type is 'module'". So an inline type="module" script is deferred by default. It is not run synchronously, even if it has no dependencies. The spec notes "Queueing a task here means that, even if the inline module script has no dependencies or synchronously results in a parse error, we won't proceed to execute the script element synchronously." With async, it runs as soon as its graph is ready.

type="module" scripts

• Default behaviour: Module scripts are deferred by default. The spec says "(The defer attribute has no effect on module scripts.)" and MDN says "they defer by default". They are fetched in parallel with parsing and evaluated when parsing finishes. The spec places them in the same list as defer scripts, so they execute in document order, interleaved with deferred classic scripts. They also run before DOMContentLoaded, which MDN confirms: DOMContentLoaded waits for "all deferred scripts (<script defer src="…"> and <script type="module">)".
• With async: The module and all its dependencies are fetched in parallel, and the module is evaluated "as soon as it is available (potentially before parsing completes)". The spec's wording there is parallel to classic async, so it has the same lack of ordering guarantee and no DOMContentLoaded guarantee.
• Dependencies: For modules, the whole import graph is fetched before evaluation. The spec's example says that "Once the entire resulting module graph has been imported, and the document has finished parsing, the contents of app.mjs will be evaluated."
• CORS: Module scripts use CORS for cross-origin fetches, which classic scripts don't (https://html.spec.whatwg.org/multipage/scripting.html).

Source disagreement. I found no real conflict between the spec and MDN. MDN's DOMContentLoaded note describes async scripts as running after the event, while the spec says they may run before parsing completes. I treat the spec as authoritative and MDN's statement as the typical case. I couldn't open the spec's parsing chapter (the URL returned 404). So the exact point where the parser fires DOMContentLoaded relies on MDN, not the spec text.

{"evidence": [
{"claim": "A plain external classic script (no async/defer) blocks parsing while it is fetched and evaluated.", "quote": "If neither attribute is present, then the script is fetched and evaluated immediately, blocking parsing until these are both complete.", "url": "https://html.spec.whatwg.org/multipage/scripting.html"},
{"claim": "Async classic scripts are fetched in parallel and evaluated as soon as available, possibly before parsing completes.", "quote": "For external classic scripts, if the async attribute is present, then the classic script will be fetched in parallel to parsing and evaluated as soon as it is available (potentially before parsing completes).", "url": "https://html.spec.whatwg.org/multipage/scripting.html"},
{"claim": "Defer classic scripts are fetched in parallel and evaluated after parsing finishes.", "quote": "If the async attribute is not present but the defer attribute is present, then the classic script will be fetched in parallel and evaluated when the page has finished parsing.", "url": "https://html.spec.whatwg.org/multipage/scripting.html"},
{"claim": "Module scripts are deferred by default; defer has no effect on them; async makes them run as soon as available.", "quote": "(The defer attribute has no effect on module scripts.)", "url": "https://html.spec.whatwg.org/multipage/scripting.html"},
{"claim": "Async and defer together: legacy fallback; MDN says async wins.", "quote": "The defer attribute may be specified even if the async attribute is specified, to cause legacy web browsers that only support defer (and not async) to fall back to the defer behavior instead of the blocking behavior that is the default.", "url": "https://html.spec.whatwg.org/multipage/scripting.html"},
{"claim": "Deferred (and non-async module) parser-inserted scripts go into an ordered list executed by the parser after parsing.", "quote": "Otherwise, if el has a defer attribute or el's type is \"module\":", "url": "https://html.spec.whatwg.org/multipage/scripting.html"},
{"claim": "Inline classic scripts are executed immediately (async/defer apply only to external classic scripts or modules); inline modules are never executed synchronously.", "quote": "Queueing a task here means that, even if the inline module script has no dependencies or synchronously results in a parse error, we won't proceed to execute the script element synchronously.", "url": "https://html.spec.whatwg.org/multipage/scripting.html"},
{"claim": "Defer scripts run after parsing but before DOMContentLoaded, and block that event until they finish.", "quote": "Scripts with the defer attribute will prevent the DOMContentLoaded event from firing until the script has loaded and finished evaluating.", "url": "https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script"},
{"claim": "Deferred scripts execute in document order.", "quote": "Scripts with the defer attribute will execute in the order in which they appear in the document.", "url": "https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script"},
{"claim": "Async scripts give no execution-order guarantee.", "quote": "You get no guarantee that scripts will run in any specific order.", "url": "https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script"},
{"claim": "async/defer have no effect on inline classic scripts.", "quote": "Warning: This attribute must not be used if the src attribute is absent (i.e., for inline scripts), in this case it would have no effect.", "url": "https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script"},
{"claim": "DOMContentLoaded waits for deferred and module scripts but not async scripts.", "quote": "It doesn't wait for other things like images, subframes, and async scripts to finish loading.", "url": "https://developer.mozilla.org/en-US/docs/Web/API/Document/DOMContentLoaded_event"},
{"claim": "readyState is interactive during deferred/module script execution; DOMContentLoaded fires after them.", "quote": "document.readyState is set to \"interactive\" after the completion of the HTML parser but before the execution of scripts with defer or type=\"module\".", "url": "https://developer.mozilla.org/en-US/docs/Web/API/Document/DOMContentLoaded_event"}
]}