In an HTML page, what actually changes if you move <script src="app.js"> from just before </body> into <head> and add the defer attribute?

## Two ways to get the same guarantee The reason people put scripts before `</body>` is a real one: a classic script with no loading attribute blocks the parser, and code that runs before the elements it touches have been parsed throws `null` errors. Putting the tag last means there is nothing left to block and nothing left to be missing. `defer` solves the same two problems differently — by keeping the tag where the browser finds it first, and postponing only the execution. ## Discovery is the real difference The HTML parser cannot fetch a resource it has not read. A `<script>` tag at the end of a long document is discovered after the parser has tokenised every byte above it, so the network request begins late. A `defer` tag in `<head>` is discovered in the first kilobytes, so the request overlaps with the parse and with fetching everything else. ```html <head> <script defer src="/app.js"></script> <!-- fetch starts now --> </head> <body> <!-- ...the whole page... --> <script src="/app.js"></script> <!-- fetch starts here instead --> </body> ``` On a fast connection and a short page the gap is small. On a slow connection and a long document it is the difference between the script being ready when parsing ends and the user waiting for a fresh round trip afterwards. ## Execution timing is close, but not the same A body-end classic script executes at the point the parser reaches it. If any markup follows the tag — even a stray closing structure, an inline snippet, or a footer someone adds later — that markup is not in the DOM yet when the code runs. A deferred script executes only after the *complete* document has been parsed, so it can never see a partial DOM. Both run before `DOMContentLoaded`. That makes `defer` strictly safer against the future edit. "It works because nothing comes after it" is a guarantee held in place by convention, not by the platform; `defer` states the guarantee in markup. ## The blocking that remains at the bottom A body-end tag without `defer` is still a parser-blocking script. Everything below it, and the completion of parsing itself, waits for the download and the execution. Since `DOMContentLoaded` fires only after parsing completes, a slow bottom-of-body script delays that event exactly as a head one would — it just delays less content on the way. ## Ordering Within each style, source order is preserved: consecutive body-end scripts run in order, and consecutive deferred scripts run in order. Mixing them is where reasoning gets awkward, because a deferred head script runs after a non-deferred body-end script even though it appears first in the document — the deferred queue drains at end of parse, and the body-end script already ran during the parse. ## What does not change Moving the tag does not make the script cheaper. It still executes on the main thread and still blocks rendering while it does. If the bundle takes 400 ms to evaluate, that cost is paid in both placements — earlier discovery just means it is paid at a more predictable moment, not that it disappears. ## The practical rule Put first-party scripts in `<head>` with `defer`. Keep an eye out for the legacy pattern in old templates — a bare `<script src>` before `</body>` — and treat converting it as a safe, mechanical improvement: it starts the download sooner and hardens the "DOM is ready" assumption against anyone appending markup below.