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 defer
is 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.
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 async
since 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.
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.
– bfavaretto
Good answer, coincided with what I read, both load asynchronously, one performs after rendering the other after loading.
defer
, instead ofasync
.– Ale
Related: When using
async
anddefer
, the order of the scripts is respected?.– Renan Gomes
Broken link from Test drive demo: HTML5 async MS must have taken it off the air already. :/
– Guilherme de Jesus Santos