Orchestrator-workers on async vs defer on <script>

Short version

Both attributes make an external classic script download in parallel with HTML parsing instead of blocking the parser. They differ in when the script runs and in what ordering you can rely on:

• defer runs the script after parsing finishes, in document order, before DOMContentLoaded.
• async runs the script as soon as it has downloaded, with no ordering guarantee and no fixed position relative to DOMContentLoaded.

Parsing

A plain <script src> with neither attribute is fetched and evaluated immediately, blocking parsing until both are done. The WHATWG spec describes the two attributes this way (https://html.spec.whatwg.org/multipage/scripting.html):

• async: the script is fetched in parallel with parsing and evaluated as soon as it is available, "potentially before parsing completes". So an async script can interrupt the parser when it arrives mid-parse.
• defer: the script is fetched in parallel and evaluated when the page has finished parsing, so it never interrupts the parser.

Timing relative to DOMContentLoaded

• defer: MDN says deferred scripts run after the document has been parsed but before DOMContentLoaded. The event is held back until they have loaded and finished evaluating (https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script). document.readyState is "interactive" while they run.

• async: the timing is not fixed.

  • The spec wording ("as soon as it is available") means a fast async script can run before parsing ends, and so before DOMContentLoaded.
  • MDN's DOMContentLoaded page says an async or dynamically injected script has often run after the event has already fired (https://developer.mozilla.org/en-US/docs/Web/API/Document/DOMContentLoaded_event).
  • The same MDN page also says DOMContentLoaded fires "before the execution of scripts with async". That is stricter than the spec wording and sits awkwardly with the possibility of an early async script. I would treat "may be before or after" as the safe statement. It depends on network timing.
• The spec's parsing and lifecycle pages returned 404 for the workers, so the exact point where the parser fires DOMContentLoaded comes from MDN, not from the spec.

Order with several scripts

• defer: deferred scripts run in the order they appear in the document. The spec queues them on a list of scripts that run when parsing finishes, and MDN states the document-order guarantee.
• async: there is no guarantee. The spec keeps async scripts in a set of scripts that run as soon as possible, and MDN says "You get no guarantee that scripts will run in any specific order." web.dev says the same (https://web.dev/learn/performance/optimize-resource-loading).

• Both attributes on one element: the sources frame this differently.

  • MDN says the element acts as if only async were specified.
  • The spec says defer may be added alongside async so that legacy browsers that support only defer fall back to deferred behavior instead of blocking.
  • These do not conflict. Modern browsers use async, and the defer is a fallback.

Inline scripts and type="module"

• Inline classic scripts (no src): async and defer have no effect. MDN says they must not be used without src. The script runs immediately and blocks the parser.

• Module scripts:

  • They are deferred by default, and defer has no effect on them. The spec puts a module without async on the same run-after-parsing list as classic defer scripts, so modules and deferred classic scripts run in document order and before DOMContentLoaded.
  • async does work on modules. The module and all its dependencies are fetched in parallel and evaluated as soon as available, potentially before parsing completes. That makes it unordered, like classic async.
  • Inline modules are also deferred by default, per web.dev (a worker report), and the spec's attribute table allows async on them. An inline module is never executed synchronously. The spec queues a task even when it has no dependencies.
• Dynamically inserted scripts: web.dev says scripts injected into the DOM behave like async scripts. The spec's "force async" flag explains this, and setting script.async = false clears it. No page I have states the resulting ordering recipe directly. That the scripts then run in insertion order is the worker's reading of the spec algorithm, not a quoted statement.

{"evidence": [
{"claim": "Spec: an external classic async script is fetched in parallel with parsing 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": "Spec: a defer script is 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": "Spec: a script with neither attribute 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": "Deferred scripts hold back DOMContentLoaded until they have loaded and finished evaluating", "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 run 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 scripts may run out of order while defer scripts keep markup order", "quote": "Additionally, async scripts may execute out-of-order, while defer scripts are executed in the order in which they appear in the markup.", "url": "https://web.dev/learn/performance/optimize-resource-loading"},
{"claim": "MDN says an async or dynamically injected script may run after DOMContentLoaded has already fired", "quote": "If it's included via <script async>, or it's dynamically injected, then by the time it executes, DOMContentLoaded has already fired.", "url": "https://developer.mozilla.org/en-US/docs/Web/API/Document/DOMContentLoaded_event"},
{"claim": "MDN also states DOMContentLoaded fires after defer/module scripts but before async scripts, which is stricter than the spec wording", "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": "When both attributes are present, MDN says async behavior wins", "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": "The spec says defer alongside async is a fallback for legacy browsers", "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": "defer (and likewise 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), in this case it would have no effect.", "url": "https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script"},
{"claim": "Module scripts are deferred by default and defer has no effect on them", "quote": "The defer attribute has no effect on module scripts — they defer by default.", "url": "https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script"},
{"claim": "With async, a module and its dependencies are fetched in parallel and evaluated as soon as available", "quote": "the module script and all its dependencies will be fetched in parallel to parsing, and the module script will be evaluated as soon as it is available (potentially before parsing completes).", "url": "https://html.spec.whatwg.org/multipage/scripting.html"},
{"claim": "In the spec's processing model, deferred classic scripts and non-async modules share the run-after-parsing 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": "Inline module scripts 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": "Dynamically injected scripts behave like async scripts, while module scripts are deferred", "quote": "Note: Scripts loaded using the type=\"module\" attribute are deferred by default, while scripts loaded by injecting <script> markup into the DOM with JavaScript behave like async scripts.", "url": "https://web.dev/learn/performance/optimize-resource-loading"}
]}