A script element is created with document.createElement('script'), given a src, and appended to the head at runtime. Does it block the HTML parser, and in what order do several scripts created this way execute?

## Parser-inserted versus script-inserted The platform distinguishes scripts the HTML parser created from scripts your code created. Only the former can block parsing, because only the former sit at a defined position in the token stream. A script element you build yourself is outside that stream entirely: ```js const s = document.createElement('script'); s.src = '/analytics.js'; document.head.append(s); ``` This never stalls parsing, even if the document is still being parsed when it runs. The fetch is kicked off when the element is inserted into the document — setting `src` alone does nothing until insertion. ## The forced-async default For a script element that was not parser-inserted, the `async` IDL attribute is `true` by default. The consequence is that the script executes as soon as its own download completes. Insert three of them in a loop and their execution order is whichever finished first — usually the smallest file, sometimes the warmest cache entry, and different on every network profile. ```js ['/lib.js', '/plugin.js', '/app.js'].forEach((src) => { const s = document.createElement('script'); s.src = src; document.head.append(s); }); // execution order: unspecified ``` This is exactly the bug shape that passes locally with everything in cache and fails one time in twenty in production, with a stack trace pointing at the dependent file rather than the loader. ## Restoring order with async = false The platform provides an explicit escape hatch. Setting `async` to `false` on a script-created element **before** it is inserted removes the forced-async behaviour and puts the element into the ordered execution list: ```js ['/lib.js', '/plugin.js', '/app.js'].forEach((src) => { const s = document.createElement('script'); s.src = src; s.async = false; // must be set before insertion document.head.append(s); }); // execution order: lib.js, plugin.js, app.js ``` All three still download in parallel, none blocks the parser, and evaluation happens in insertion order. This is the mechanism every hand-written script loader relies on, and it is the answer the question is really fishing for. Two details matter: the assignment must happen before the element enters the document, and the ordering guarantee holds among the scripts marked this way — a separate forced-async script inserted alongside them stays unordered. ## Handling completion and failure There is no synchronous signal. You listen on the element: ```js s.addEventListener('load', onReady); s.addEventListener('error', onFailed); ``` The `error` event fires for a network failure or a non-successful response, but **not** for an exception thrown inside the script — that surfaces as a normal uncaught error on `window`. Distinguishing "never arrived" from "arrived and threw" is a question people get wrong, and it changes whether a retry is sensible. A cross-origin script also reports exceptions opaquely as `"Script error."` unless the response carries the appropriate CORS header and the element carries `crossorigin`, which is worth setting on any third-party script whose failures you intend to monitor. ## When to reach for this at all Dynamic insertion is right when the decision to load is conditional: a consent gate, a route that needs a heavy editor, a feature flag, a third-party widget that should only appear for some users. It is the wrong tool for the application's own entry point, where a `defer` or module tag in the markup is discovered earlier and needs no code to run first. A dynamically inserted script cannot be found until the script that inserts it has itself downloaded and executed, so every such load starts at least one round trip late. If the URL is known up front but the decision is not, `<link rel="preload" as="script">` can warm the cache so the later insertion resolves quickly. ## The short answer Never parser-blocking; async by default; `async = false` before insertion buys you insertion-order execution; use the `load` and `error` events, and remember that `error` does not fire for a throwing script.