In modern websites, scripts are often “heavier” than HTML: their download size is larger, and processing time is also longer.
When the browser loads HTML and comes across a
<script>...</script> tag, it can’t continue building the DOM. It must execute the script right now. The same happens for external scripts
<script src="..."></script>: the browser must wait for the script to download, execute the downloaded script, and only then can it process the rest of the page.
That leads to two important issues:
- Scripts can’t see DOM elements below them, so they can’t add handlers etc.
- If there’s a bulky script at the top of the page, it “blocks the page”. Users can’t see the page content till it downloads and runs:
There are some workarounds to that. For instance, we can put a script at the bottom of the page. Then it can see elements above it, and it doesn’t block the page content from showing:
But this solution is far from perfect. For example, the browser notices the script (and can start downloading it) only after it downloaded the full HTML document. For long HTML documents, that may be a noticeable delay.
Such things are invisible for people using very fast connections, but many people in the world still have slow internet speeds and use a far-from-perfect mobile internet connection.
Luckily, there are two
<script> attributes that solve the problem for us:
defer attribute tells the browser not to wait for the script. Instead, the browser will continue to process the HTML, build DOM. The script loads “in the background”, and then runs when the DOM is fully built.
Here’s the same example as above, but with
In other words:
- Scripts with
defernever block the page.
- Scripts with
deferalways execute when the DOM is ready (but before
The following example demonstrates the second part:
- The page content shows up immediately.
DOMContentLoadedevent handler waits for the deferred script. It only triggers when the script is downloaded and executed.
Deferred scripts keep their relative order, just like regular scripts.
Let’s say, we have two deferred scripts: the
long.js and then
Browsers scan the page for scripts and download them in parallel, to improve performance. So in the example above both scripts download in parallel. The
small.js probably finishes first.
defer attribute, besides telling the browser “not to block”, ensures that the relative order is kept. So even though
small.js loads first, it still waits and runs after
deferattribute is only for external scripts
defer attribute is ignored if the
<script> tag has no
async attribute is somewhat like
defer. It also makes the script non-blocking. But it has important differences in the behavior.
async attribute means that a script is completely independent:
- The browser doesn’t block on
- Other scripts don’t wait for
asyncscripts don’t wait for them.
DOMContentLoadedand async scripts don’t wait for each other:
DOMContentLoadedmay happen both before an async script (if an async script finishes loading after the page is complete)
- …or after an async script (if an async script is short or was in HTTP-cache)
In other words,
async scripts load in the background and run when ready. The DOM and other scripts don’t wait for them, and they don’t wait for anything. A fully independent script that runs when loaded. As simple, as it can get, right?
Here’s an example similar to what we’ve seen with
defer: two scripts
small.js, but now with
async instead of
They don’t wait for each other. Whatever loads first (probably
small.js) – runs first:
- The page content shows up immediately:
asyncdoesn’t block it.
DOMContentLoadedmay happen both before and after
async, no guarantees here.
- A smaller script
small.jsgoes second, but probably loads before
small.jsruns first. Although, it might be that
long.jsloads first, if cached, then it runs first. In other words, async scripts run in the “load-first” order.
Async scripts are great when we integrate an independent third-party script into the page: counters, ads and so on, as they don’t depend on our scripts, and our scripts shouldn’t wait for them:
<!-- Google Analytics is usually added like this --> <script async src="https://google-analytics.com/analytics.js"></script>
asyncattribute is only for external scripts
async attribute is ignored if the
<script> tag has no
There’s one more important way of adding a script to the page.
The script starts loading as soon as it’s appended to the document
Dynamic scripts behave as “async” by default.
- They don’t wait for anything, nothing waits for them.
- The script that loads first – runs first (“load-first” order).
This can be changed if we explicitly set
script.async=false. Then scripts will be executed in the document order, just like
In this example,
loadScript(src) function adds a script and also sets
long.js always runs first (as it’s added first):
script.async=false, scripts would execute in default, load-first order (the
small.js probably first).
Again, as with the
defer, the order matters if we’d like to load a library and then another script that depends on it.
defer have one common thing: downloading of such scripts doesn’t block page rendering. So the user can read page content and get acquainted with the page immediately.
But there are also essential differences between them:
||Load-first order. Their document order doesn’t matter – which loads first runs first||Irrelevant. May load and execute while the document has not yet been fully downloaded. That happens if scripts are small or cached, and the document is long enough.|
||Document order (as they go in the document).||Execute after the document is loaded and parsed (they wait if needed), right before
defer is used for scripts that need the whole DOM and/or their relative execution order is important.
async is used for independent scripts, like counters or ads. And their relative execution order does not matter.
Please note: if you’re using
async, then user will see the page before the script loads.
In such case, some graphical components are probably not initialized yet.
Don’t forget to put “loading” indication and disable buttons that aren’t functional yet. Let the user clearly see what he can do on the page, and what’s still getting ready.
<code>tag, for several lines – wrap them in
<pre>tag, for more than 10 lines – use a sandbox (plnkr, jsbin, codepen…)