About the boolean attribute Defer and async vs optimization

Asked

Viewed 5,560 times

19

The use of async and defer for optimization is a good subject to touch when we want pages loaded more quickly and also without blocking problems.

Doubts:

  • Using async, if the browser does not support, it ignores the attribute and drops/executes the script normally, or it simply ignores it, not loading it?
  • whereas the objective of async and of defer, is to perform the loading of scripts without interrupting/blocking the page rendering, it would not be the same thing as putting them (the scripts) before the </body>? Or by asynchronously loading, it’s faster since it doesn’t depend on the rendering being completed?
  • Libraries for asynchronous loading, such as Labjs, yet are useful in view of these attributes(async/defer)? Or they are somewhat safer, ensuring asynchronous charging regardless of browser version?
  • whereas the defer allows the script to be loaded from asynchronous form, but only allows its execution after rendering, he may be better than the async, since it executes after the loading, even if rendering is still taking place?

1 answer

21


Using async, if the browser does not support, it ignores the attribute and drops/executes the script normally, or it simply ignores it, not carrying it?

It ignores only the attribute, the script is normally downloaded as if there were no defer or async, that is, blocking the parse page. You can better check which browsers support these attributes through the links: async and Defer.

The async is a new attribute already the defer, if I’m not mistaken it was implemented by Microsoft a long time ago and then the other browsers started to support the newer versions. You can use the technique of combining the two attributes to prevent rendering locking and continue downloading the scripts in the background:

<script src='meuscript-js' async defer></script>

If the user’s browser supports both attributes, async shall prevail. In the event that async, the attribute will be ignored and then defer will be used. Important: The order of execution after download is different and will be explained in the next question.

whereas the objective of async and of deferis to accomplish the loading scripts without interrupting/blocking the rendering of page, wouldn’t be the same thing as putting them (the scripts) before the </body>? Or by charging asynchronously, it is faster since not depends on whether the rendering is completed?

It should not take into consideration only the "load asynchronously", it is noteworthy that each attribute has a behavior and serves for a purpose.

Execução
Reference

async should be used to scripts which can be executed regardless of whether the document is ready or not. The script will be downloaded without interrupting the parse from the page and run right away. In the reference link above, a very simple example to illustrate are the Google Analytics scripts. There is no need for the DOM to be ready for them to be executed.

defer should be used to scripts which must be executed only when the document is ready. To illustrate, a script that handles the event of click on a tag <a> in the GIFT.

And just to be clear, it’s not the same thing. Before </body>:

<script src='a.js'></script> <!-- será baixado e executado. -->
<script src='b.js'></script> <!-- será baixado depois de 'a.js' e executado. -->
<script src='c.js'></script> <!-- será baixado depois de 'b.js' e executado. -->

Already with async:

<!--
  Serão baixados todos ao mesmo tempo e executados após o download.
  Eles serão requisitados paralelamente e executados na sequência.
-->
<script async src='a.js'></script>
<script async src='b.js'></script>
<script async src='c.js'></script>

And with defer:

<!--
  Serão baixados todos ao mesmo tempo e executados somente quando a
  renderização do documento estiver concluída. Assim como o 'async',
  eles serão requisitados paralelamente e executados na sequência.
-->
<script defer src='a.js'></script>
<script defer src='b.js'></script>
<script defer src='c.js'></script>

Asynchronous loading libraries, such as Labjs, are still useful in view of these attributes (async/defer)? Or they are from certain way safer, ensuring asynchronous charging regardless of the browser version?

Here’s the compatibility issue. I don’t know these libraries, but they certainly have the purpose (besides the "asynchronous loading") to overcome the incompatibility of browsers. If you don’t want to have surprises with async and defer, use a library to handle this.
See this article in CSS-Tricks

whereas the defer allows the script to be loaded from asynchronous form, but only allows its execution after rendering, it may be better than the asyncsince this one executes after the loading, even if the rendering is still taking place?

I do not see one being better than the other because they do not serve for the same thing, although both download the script without interrupting the rendering but the way these scripts will be executed works differently.

Scripts that use attribute async and defer make a bigger difference when they are not located so at the end of the document. How HTML parsing occurs from left to right, from top to bottom, starting with the first declared element <html>, until when it is closed. If any script is located just before the element </body>, the use of attributes becomes redundant async and defer.

As the document analysis is almost complete at that point, these script elements don’t have much to block.

  • 4

    Your answer is much more correct than mine (which I just deleted). From what I’ve been reading, none of the attributes determines how the script will be charged, only the moment it will be executed. The "asynchronous loading" obtained with them is a side effect, since they eliminate the need to immediately block the document processing to run the script. That’s what I understood from the specification and other articles I read.

  • Good answer, coincided with what I read, both load asynchronously, one performs after rendering the other after loading. defer, instead of async.

  • 1

    Broken link from Test drive demo: HTML5 async MS must have taken it off the air already. :/

Browser other questions tagged

You are not signed in. Login or sign up in order to post.