For an external classic script in HTML — <script src="a.js"></script> — what is the difference between adding the async attribute and adding the defer attribute, both in when the script executes and in what ordering guarantees you get across several such scripts?

## Three loading modes, not two An external classic script has three behaviours available: ```html <script src="a.js"></script> <!-- blocking: fetch and run with the parser stopped --> <script src="a.js" async></script> <!-- fetch in parallel, run the moment it lands --> <script src="a.js" defer></script> <!-- fetch in parallel, run after parsing, in order --> ``` Everything below is about the second and third. ## What both share Both attributes decouple the *download* from parsing. The browser starts the request when it encounters the element and keeps building the DOM while the bytes are in flight. Neither attribute has any effect on an inline classic script — `<script async>code()</script>` with no `src` runs immediately and synchronously, exactly as if the attribute were absent. ## async: run as soon as available An `async` script executes at the first opportunity after its download completes. If the document is still being parsed at that moment, the parser is paused, the script runs, and parsing resumes. So `async` removes the *network* stall but not necessarily the *execution* stall — it just moves it to an unpredictable point. The consequence people miss is ordering. Given ```html <script src="jquery.js" async></script> <script src="jquery-plugin.js" async></script> ``` the plugin can and will sometimes run first, because it is smaller and finishes downloading sooner. There is no guarantee tying execution order to document order, to file size, or to anything else you can control. Async scripts also make no promise about `DOMContentLoaded`: one may execute before it or after it, and it may find the element it wants missing. That makes `async` correct for exactly one shape of script: self-contained, dependency-free, and indifferent to whether the DOM is ready — an analytics beacon, an error reporter, a feature-flag ping. ## defer: run after parsing, in order A `defer` script is added to a list that the browser executes once parsing of the document is complete. The guarantees are strong and worth memorising: - Deferred scripts never interrupt parsing at any point. - They execute in **document order**, regardless of which finished downloading first — a slow first script holds back a fast second one. - They all execute before `DOMContentLoaded` fires, so that event is a reliable "all deferred code has run" signal. - The DOM is fully built when they run, so querying elements is safe. That combination is why `defer` is the sensible default for application code. It gives you early discovery (the tag can sit in `<head>`), parallel download, ordered execution, and a ready DOM. ## Choosing between them Ask two questions. *Does this script depend on another script or on the DOM?* If yes, it cannot be `async`. *Does anything depend on this script running before something else?* If yes, it cannot be `async` either. Everything that survives both questions can be `async`; everything else gets `defer`. A useful sanity check: two `async` tags where one is a library and the other its plugin is a bug that will look like a flaky, environment-dependent "undefined is not a function" in production and pass every time on a warm local cache. ## Edge cases interviewers probe **Both attributes on one tag.** `<script src="a.js" async defer>` behaves as `async` in any browser that supports `async`; `defer` was left in as a fallback for ancient browsers that supported only `defer`. In practice, writing both today just means `async`. **Injected scripts.** Adding `async` or `defer` to markup is not the same as creating an element in JavaScript — a script element created with `document.createElement` has its own default behaviour, which is a separate topic. **Blocking is still available and sometimes wanted.** A tiny inline configuration snippet that must run before a deferred bundle sees it is legitimately synchronous. ## The one-sentence version `async` = parallel download, execute immediately, order unspecified; `defer` = parallel download, execute after parsing in document order. Saying only "both load in the background" is the answer that fails, because it omits the only part the interviewer is testing.