Plan-execute on async vs defer on <script>

Short answer: async and defer let the browser download an external classic script while it keeps parsing the HTML. They differ in when the script runs:

• defer waits until parsing is finished, runs scripts in the order they appear in the document, and finishes before DOMContentLoaded.
• async runs each script as soon as it has downloaded, in no particular order, which can be before or after DOMContentLoaded.

Neither attribute does anything on an inline classic script. Module scripts are deferred by default, and on them only async makes a difference.

1. Baseline: a classic script with neither attribute. For an external classic script with no async or defer, "the script is fetched and evaluated immediately, blocking parsing until these are both complete" (https://html.spec.whatwg.org/multipage/scripting.html). MDN says the same thing, and adds that such a script blocks parsing but not rendering (https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script).

2. async.

• Parsing: the script is "fetched in parallel to parsing and evaluated as soon as it is available (potentially before parsing completes)" (WHATWG). Download doesn't block the parser, but running the script does pause it. web.dev puts it this way: async scripts "can interrupt DOM building if they finish downloading while the parser is still at work" (https://web.dev/articles/efficiently-load-third-party-javascript).
• Order: none. In the spec's algorithm, async scripts go into an unordered "set of scripts that will execute as soon as possible", and each one runs when its own download finishes (WHATWG). MDN: "You get no guarantee that scripts will run in any specific order."
• DOMContentLoaded: the event doesn't wait for async scripts (https://developer.mozilla.org/en-US/docs/Web/API/Document/DOMContentLoaded_event). An async script can therefore run before the event (if it arrives while the parser is still working) or after it. The sources disagree here: a note on that same MDN page says DOMContentLoaded fires "before the execution of scripts with async". That conflicts with the spec's "potentially before parsing completes" and with web.dev's "interrupt DOM building". I treat the MDN note as a simplification of the common case, not a guarantee.

3. defer.

• Parsing: the script is fetched in parallel and run "when the page has finished parsing" (WHATWG), so it never blocks the parser.
• Order: deferred scripts go into a "list of scripts that will execute when the document has finished parsing" and run in the order they appear in the document (WHATWG; MDN).
• DOMContentLoaded: deferred scripts run after parsing but before the event, and they hold the event back until they finish (MDN script page; MDN DOMContentLoaded page; web.dev).
• Wording conflict: MDN's summary also says deferred scripts "will only execute once everything has finished loading". Its own attribute reference and the spec say "after parsing", not after the whole page (images and so on) has loaded.

4. Both attributes on one script. async wins. The spec allows adding defer alongside async only so that old browsers that support defer but not async fall back to deferring instead of blocking (WHATWG; MDN).

5. Inline classic scripts (no src). The spec's mode descriptions apply only to external classic scripts. In its processing model, inline classic scripts never join the async or deferred queues; the browser runs them immediately (WHATWG). MDN says both attributes "must not be used if the src attribute is absent" because they would have no effect, and that inline scripts without type="module" "are fetched and executed immediately before the browser continues to parse the page."

6. type="module".

• Without async: a module script and its dependencies are fetched in parallel and run after parsing finishes, in the same deferred list as defer scripts. "The defer attribute has no effect on module scripts" (WHATWG; MDN). DOMContentLoaded also waits for these scripts (MDN DOMContentLoaded page).
• With async: the module runs as soon as it and its dependencies are ready, possibly before parsing completes.
• Inline modules: unlike inline classic scripts, these go through the same queues, so async does work on them. The spec always queues a task before an inline module runs, so it never executes synchronously, even if it has no imports (WHATWG).

Related case: scripts inserted by JavaScript (not by the parser) behave as if they had async by default (the spec calls this "force async"). If you turn that off, they go into a "list of scripts that will execute in order as soon as possible" (WHATWG).

Changes from the plan: the plan said to cite the WHATWG parsing page and javascript.info, but both URLs returned HTTP 404. I used MDN's DOMContentLoaded page and web.dev instead for event timing. MDN's <script> URL redirected to /Web/HTML/Reference/Elements/script, and I cite that final URL.

{"evidence": [
{"claim": "A classic external script with neither attribute blocks parsing while it is fetched and run.", "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": "An async classic script is fetched in parallel with parsing and runs as soon as it is ready, possibly before parsing ends.", "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": "Async scripts can interrupt the parser when they run, and their order is not guaranteed.", "quote": "It also means they can interrupt DOM building if they finish downloading while the parser is still at work.", "url": "https://web.dev/articles/efficiently-load-third-party-javascript"},
{"claim": "There is no ordering guarantee among async scripts.", "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": "DOMContentLoaded waits for deferred and module scripts but not for async scripts.", "quote": "The DOMContentLoaded event fires when the HTML document has been completely parsed, and all deferred scripts (<script defer src=\"…\"> and <script type=\"module\">) have downloaded and executed.", "url": "https://developer.mozilla.org/en-US/docs/Web/API/Document/DOMContentLoaded_event"},
{"claim": "An MDN note says DOMContentLoaded fires before async scripts run, which conflicts with the spec's 'potentially 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": "A deferred script runs after parsing but before DOMContentLoaded.", "quote": "This Boolean attribute is set to indicate to a browser that the script is meant to be executed after the document has been parsed, but before firing DOMContentLoaded event.", "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": "The spec keeps deferred scripts in an ordered list that runs when parsing finishes.", "quote": "Each Document has a list of scripts that will execute when the document has finished parsing, which is a list of script elements, initially empty.", "url": "https://html.spec.whatwg.org/multipage/scripting.html"},
{"claim": "When both attributes are set, async wins; defer is only a fallback for old 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": "Inline classic scripts run immediately and block parsing; async and defer have no effect on them.", "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": "Module scripts are deferred by default; defer does nothing 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": "An async module script runs as soon as it and its dependencies are ready.", "quote": "For module scripts, if the async attribute is present, then 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": "Inline module scripts never run synchronously, 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"}
]}