Why is a third-party snippet that calls document.write() from a <script> tag a problem for HTML page loading, and what happens if the same call runs after the document has finished parsing?

## What document.write actually does `document.write()` does not append to the page. It writes a string **into the parser's input stream** at the current insertion point — the position the HTML parser has reached. The parser then tokenises that string as if it had arrived over the network at exactly that spot. This is why the API exists at all: it predates the DOM and was designed for a document being streamed and parsed top to bottom. ```html <p>before</p> <script>document.write('<p>injected</p>');</script> <p>after</p> ``` The injected paragraph lands between the other two, because that is where the parser was. ## Why it hurts loading The script itself is already parser-blocking. On top of that, the written markup must be tokenised before parsing can continue, and if it contains a script tag the browser must fetch that file too — synchronously, from a URL it could not know about in advance. Browsers normally soften blocking scripts with a preload scanner: while the parser is stalled, a lookahead scanner reads further down the raw bytes and starts fetching the images, stylesheets and scripts it finds. Markup that does not exist until a script runs is invisible to that scanner. So a `document.write`-injected script is a fully serialised round trip: parse, stall, fetch, run, write, fetch again. Chains of these — a tag manager writing a vendor tag which writes another — are a well-known source of multi-second stalls. That cost is severe enough that Chrome shipped an intervention: for users on slow connections, it may block a parser-blocking script that was injected via `document.write` from a cross-origin URL, logging a console warning instead of running it. The practical consequence is that a snippet written this way is not merely slow — it may not execute at all for part of your audience, and the vendor's dashboard shows missing data with no error on your side. ## The ignored case If the calling script is `async`, deferred, or a module, its `document.write()` calls are ignored. At that moment the parser has no insertion point for the script, so the write is discarded. This produces one of the more confusing symptoms in the wild: adding `async` to a vendor tag to "make it faster" makes it stop working entirely, with no exception thrown. ## The destructive case After the document has finished loading, calling `document.write()` implicitly calls `document.open()` first. `document.open()` clears the document — the entire existing DOM, and the event listeners attached to it — and starts a fresh one to receive what you write. So a call from a click handler, a `setTimeout`, or a late-arriving callback blanks the page and replaces it with the written string. Nothing crashes; the page just disappears. ```javascript button.addEventListener('click', () => { document.write('hello'); // wipes the page it was clicked on }); ``` ## What to do instead Insert content by building nodes and attaching them, or by setting markup on an element you own. For loading another script, create the element and append it rather than writing a tag string — that path is asynchronous by default and never touches the parser's input stream. When a vendor's snippet insists on `document.write`, the options are: ask for their asynchronous loader (most now have one), load their tag inside an iframe so the destructive write is contained, or drop the tag. ## Answering well A strong answer separates the three states — during parsing it is parser-blocking and hides work from the preload scanner; from async or deferred code it is ignored; after load it destroys the document — and finishes with the concrete modern consequence, that a browser may refuse to run the injected script at all on a slow connection.