Propose-select 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 whether order is guaranteed. async runs the script as soon as it has arrived, in no guaranteed order. defer runs it after parsing finishes, in document order, before DOMContentLoaded.

What each does

No attribute. A plain external classic script is fetched and run immediately, and the parser stops until both are done. The spec says: "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. For an external classic script, "the classic script will be fetched in parallel to parsing and evaluated as soon as it is available (potentially before parsing completes)." (https://html.spec.whatwg.org/multipage/scripting.html)

• Downloading doesn't block the parser, but execution does interrupt it. MDN says the executing script "blocks the page from rendering" (https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script).
• In the spec's processing model, an async script goes into a "set of scripts that will execute as soon as possible". It is a set, so nothing orders its entries.

defer. The classic script "will be fetched in parallel and evaluated when the page has finished parsing." (https://html.spec.whatwg.org/multipage/scripting.html)

• The spec appends such scripts to a "list of scripts that will execute when the document has finished parsing", and the parser runs them from that list.
• MDN describes the timing as after the document has been parsed but before DOMContentLoaded fires (https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script).

Both together. async wins. MDN says "the element will act as if only the async attribute is specified." The spec says authors may still write both so that legacy browsers that only know defer fall back to deferred behaviour instead of blocking. (https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script and https://html.spec.whatwg.org/multipage/scripting.html)

Timing relative to DOMContentLoaded

• defer scripts hold up DOMContentLoaded. MDN's event page says it fires once the document is parsed "and all deferred scripts (<script defer src="…"> and <script type="module">) have downloaded and executed." It also 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)
• The sequence for deferred scripts. document.readyState becomes "interactive" when parsing completes, before the deferred and module scripts run. DOMContentLoaded then fires after they finish. (same MDN event page)
• async scripts have no fixed position. DOMContentLoaded doesn't wait for them. An async script that arrives early can run before parsing ends, and so before DOMContentLoaded. A slow one runs after it. Code in an async script should check document.readyState instead of assuming either case.
• A difference in wording between the sources. The spec says an async script may run "potentially before parsing completes". A note on MDN's event page says DOMContentLoaded fires "before the execution of scripts with async." The spec's wording is the broader one. Treat the MDN note as describing the common case, not a guarantee.

Execution order with several scripts

• async: no ordering guarantee. MDN says "You get no guarantee that scripts will run in any specific order." Its example of three async scripts warns that a script depending on jQuery may run before jQuery has loaded. Use async only for independent scripts. (https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script)
• defer: document order. MDN says "Scripts with the defer attribute will execute in the order in which they appear in the document." This holds even if a later script finishes downloading first, because the spec runs them from an ordered list. (https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script)
• Dynamically inserted scripts. Scripts created with document.createElement have "force async" set to true, so they behave as async unless you set script.async = false. In that case they go into a separate in-order list and run in insertion order, without waiting for parsing to finish. (https://html.spec.whatwg.org/multipage/scripting.html)

Inline scripts

async and defer apply only to external classic scripts.

• MDN says that for inline classic scripts the attribute "would have no effect." (https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script)
• A plain inline classic script runs immediately when the parser reaches it, and it blocks parsing. MDN says such scripts "are fetched and executed immediately before the browser continues to parse the page."

type="module" scripts

• Deferred by default. The spec says "Otherwise, the module script and its dependencies will be fetched in parallel to parsing and evaluated when the page has finished parsing. (The defer attribute has no effect on module scripts.)" (https://html.spec.whatwg.org/multipage/scripting.html)
• Same ordered list as defer. In the spec's algorithm, a parser-inserted script goes into the post-parsing ordered list if it "has a defer attribute or el's type is "module"". Module scripts therefore run in document order, before DOMContentLoaded, alongside deferred classic scripts. Placement in the document doesn't change this.
• async on modules. The module and all its dependencies are fetched in parallel and run as soon as they are available, possibly before parsing completes. There is no ordering guarantee, as with async classic scripts.
• Inline modules are the exception to the inline rule. The spec's attribute table allows async on inline module scripts. Without async, an inline module is deferred. With async, it goes into the as-soon-as-possible set. Unlike an inline classic script, it never runs synchronously at parse time. The spec says it always waits for a queued task, even when it has no dependencies.

{"evidence": [
{"claim": "A plain external classic script 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 run as soon as available, possibly before parsing completes", "quote": "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 run once parsing has finished", "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 and defer has no effect on them", "quote": "(The defer attribute has no effect on module scripts.)", "url": "https://html.spec.whatwg.org/multipage/scripting.html"},
{"claim": "Module scripts wait for parsing to finish regardless of where they appear in the document", "quote": "no matter where this script element appears in the document, it will not be evaluated until both document parsing has complete", "url": "https://html.spec.whatwg.org/multipage/scripting.html"},
{"claim": "Parser-inserted deferred and module scripts share the same post-parsing ordered list", "quote": "Otherwise, if el has a defer attribute or el's type is \"module\":", "url": "https://html.spec.whatwg.org/multipage/scripting.html"},
{"claim": "Setting both async and defer is allowed so legacy defer-only browsers fall back to deferred behaviour", "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": "With both attributes present, async takes precedence", "quote": "If the attribute is specified with the async attribute, the element will act as if only the async attribute is specified.", "url": "https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script"},
{"claim": "defer scripts run before DOMContentLoaded and hold it up 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": "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": "MDN's event page says DOMContentLoaded fires before async scripts execute (the spec instead says async may run before parsing completes)", "quote": "DOMContentLoaded is fired after the execution of these scripts, but before the execution of scripts with async.", "url": "https://developer.mozilla.org/en-US/docs/Web/API/Document/DOMContentLoaded_event"},
{"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 have no ordering 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 has no effect on inline classic scripts", "quote": "This attribute must not be used if the src attribute is absent (i.e., for inline scripts) for classic scripts, in this case it would have no effect.", "url": "https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script"},
{"claim": "Inline non-module scripts run immediately during parsing", "quote": "Scripts without async, defer or type=\"module\" attributes, as well as inline scripts without the type=\"module\" attribute, are fetched and executed immediately before the browser continues to parse the page.", "url": "https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script"},
{"claim": "async on module scripts fetches the module and its dependencies in parallel and runs it as soon as available", "quote": "For module scripts, if the async attribute is present then the scripts and all their dependencies will be fetched in parallel to parsing and evaluated as soon as they are available.", "url": "https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script"},
{"claim": "Parser-inserted scripts have force async false, while dynamically created scripts default to force async true", "quote": "A script element has a force async boolean, initially true. It is set to false by the HTML parser and the XML parser on script elements they insert, and when the element gets an async content attribute added.", "url": "https://html.spec.whatwg.org/multipage/scripting.html"},
{"claim": "Inline module scripts are not run synchronously; they are queued as a task even with no dependencies", "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"}
]}