An HTML document has <script src="app.js"></script> in its <head> with no other attributes. What does the HTML parser do when it reaches that tag, and why does moving the same tag to just before </body> change what the user sees?

## What "parser-blocking" actually means The browser parses an HTML response as a stream, building DOM nodes as bytes arrive. A `<script>` element with no `async`, no `defer`, and no `type="module"` — a *classic, parser-inserted* script — interrupts that stream. The parser stops adding nodes at exactly that point, hands control to the JavaScript engine, and does not resume until the script has finished running. When the element has a `src`, the pause covers the network round trip as well as the execution. ```html <head> <script src="app.js"></script> </head> <body> <h1>Everything here is still unparsed bytes</h1> </body> ``` While `app.js` is in flight, the `<h1>` is not a node, not styled, and not paintable. It is still text sitting in a buffer. ## Why the browser is forced to do this This is a correctness requirement, not an oversight. A classic script may call `document.write()`, which inserts markup into the token stream *at the script's own position*. Because the script can change the very bytes the parser is about to consume, the parser is not allowed to run ahead of it. That one legacy API is why synchronous execution is the default, and why `async` and `defer` had to be introduced as explicit opt-ins rather than simply becoming the new behaviour. ## What the user experiences DOM construction is a prerequisite for showing anything, so a blocked parser is a blocked page. A script in `<head>` that needs 800 ms to fetch on a slow mobile connection leaves the user looking at a blank or stale screen for 800 ms, even though the bytes for the header, nav, and hero arrived long ago. Two separate costs are hiding in that number: the *fetch* (waiting on the network) and the *execution* (parsing and running the JavaScript, which occupies the main thread). Both happen with the parser stopped, and both scale with the script's size. Modern browsers soften the first cost: while blocked, they scan ahead in the raw response bytes for resource URLs and start those downloads early. That is a download optimisation only — the script still executes in place, in source order, and the parser still waits for it. ## The second consequence: a head script sees an empty document Because the parser has not reached the body yet, anything the script queries in the document is missing. `document.getElementById('root')` is `null`, `document.body` may itself be `null`, and adding a listener to a button that has not been parsed silently does nothing. Code that runs in `<head>` therefore has to defer its DOM work until parsing has finished, which is the origin of the habit of wrapping everything in a "wait for the document" callback. ## The end-of-body placement Putting the tag immediately before `</body>` sidesteps both problems without any attribute: by the time the parser reaches it, the whole document has been built, so the content is already displayable and every element the script wants is in the DOM. The tradeoff is *discovery time* — the browser cannot begin the download until it has parsed all the markup above it, so on a large page the request starts late. The scan-ahead behaviour recovers much of that, but not all of it, and the script still runs synchronously once it arrives. ## What you would actually write today `defer` on the same tag in `<head>` gives you both halves: the element is discovered immediately so the download starts at once, the fetch happens in parallel with parsing, and execution is postponed until parsing is complete, in document order. `type="module"` behaves as deferred by default. The end-of-body trick is still correct and still common in hand-written HTML, but it is a workaround from before those attributes existed. One detail that trips people up: `async` and `defer` are ignored on an **inline** classic script. `<script defer>init()</script>` with no `src` runs immediately and synchronously, blocking the parser exactly like an unattributed one. There is no download to parallelise, but the execution stall is real, and a long inline script in `<head>` is a genuine cause of slow first paints. ## How to answer this in an interview Say "parser-blocking", name both costs (download *and* execution), give `document.write` as the reason the default exists, and finish with the modern fix rather than only the historical one. That is the complete answer; "scripts go at the bottom" on its own is the slogan version.