我有几个关于<script>标签的async和defer属性的问题,据我的理解,它只在HTML5浏览器中工作。

我的一个站点有两个外部JavaScript文件,目前位于</body>标记上方;第一个是来自谷歌的jquery,第二个是一个本地外部脚本。

在网站加载速度方面

在我在页面底部的两个脚本中添加async是否有任何优势? 在这两个脚本中添加async选项并将它们放在<head>的页面顶部是否有任何优势? 这是否意味着他们会在页面加载时下载? 我认为这会导致HTML4浏览器的延迟,但是它会加速HTML5浏览器的页面加载吗?

使用<script defer src=…

在<head>中加载带有属性的两个脚本是否与在</body>之前加载脚本具有相同的影响? 同样,我认为这会降低HTML4浏览器的速度。

使用<script async src=…

如果我有两个脚本异步启用

他们会同时下载吗? 还是一页一页地看? 脚本的顺序会成为问题吗?例如,一个脚本依赖于另一个脚本,所以如果一个脚本下载得更快,第二个脚本可能无法正确执行等等。

最后,在HTML5得到更广泛的应用之前,我是否应该保持现状?


当前回答

HTML5:异步,延迟

在HTML5中,你可以告诉浏览器什么时候运行JavaScript代码。有三种可能:

<script       src="myscript.js"></script>

<script async src="myscript.js"></script>

<script defer src="myscript.js"></script>

没有async或defer,浏览器会立即运行你的脚本,在呈现脚本标签下面的元素之前。 使用async(异步),浏览器将继续加载HTML页面并在浏览器加载和执行脚本的同时呈现它。 使用defer,浏览器将在页面完成解析时运行您的脚本。(没有必要下载完所有图像文件。这很好。)

其他回答

async和defer脚本都立即开始下载,而不需要暂停解析器,并且都支持可选的onload处理程序,以满足执行初始化(依赖于脚本)的常见需求。

The difference between async and defer centers around when the script is executed. Each async script executes at the first opportunity after it is finished downloading and before the window’s load event. This means it’s possible (and likely) that async scripts are not executed in the order in which they occur in the page. Whereas the defer scripts, on the other hand, are guaranteed to be executed in the order they occur in the page. That execution starts after parsing is completely finished, but before the document’s DOMContentLoaded event.

来源和更多细节:这里。

我认为杰克·阿奇博尔德在2013年向我们展示了一些见解,可能会为这个话题增添更多的积极因素:

https://www.html5rocks.com/en/tutorials/speed/script-loading/

The holy grail is having a set of scripts download immediately without blocking rendering and execute as soon as possible in the order they were added. Unfortunately HTML hates you and won’t let you do that. (...) The answer is actually in the HTML5 spec, although it’s hidden away at the bottom of the script-loading section. "The async IDL attribute controls whether the element will execute asynchronously or not. If the element's "force-async" flag is set, then, on getting, the async IDL attribute must return true, and on setting, the "force-async" flag must first be unset…". (...) Scripts that are dynamically created and added to the document are async by default, they don’t block rendering and execute as soon as they download, meaning they could come out in the wrong order. However, we can explicitly mark them as not async:

[
    '//other-domain.com/1.js',
    '2.js'
].forEach(function(src) {
    var script = document.createElement('script');
    script.src = src;
    script.async = false;
    document.head.appendChild(script);
});

This gives our scripts a mix of behaviour that can’t be achieved with plain HTML. By being explicitly not async, scripts are added to an execution queue, the same queue they’re added to in our first plain-HTML example. However, by being dynamically created, they’re executed outside of document parsing, so rendering isn’t blocked while they’re downloaded (don’t confuse not-async script loading with sync XHR, which is never a good thing). The script above should be included inline in the head of pages, queueing script downloads as soon as possible without disrupting progressive rendering, and executes as soon as possible in the order you specified. “2.js” is free to download before “1.js”, but it won’t be executed until “1.js” has either successfully downloaded and executed, or fails to do either. Hurrah! async-download but ordered-execution!

不过,这可能不是加载脚本的最快方式:

(…)对于上面的示例,浏览器必须解析和执行脚本以发现要下载哪些脚本。这将从预加载扫描器中隐藏脚本。浏览器使用这些扫描器来发现您接下来可能访问的页面上的资源,或者在解析器被其他资源阻塞时发现页面资源。 我们可以通过在文档头部添加以下内容来增加可发现性:

<link rel="subresource" href="//other-domain.com/1.js">
<link rel="subresource" href="2.js">

This tells the browser the page needs 1.js and 2.js. link[rel=subresource] is similar to link[rel=prefetch], but with different semantics. Unfortunately it’s currently only supported in Chrome, and you have to declare which scripts to load twice, once via link elements, and again in your script. Correction: I originally stated these were picked up by the preload scanner, they're not, they're picked up by the regular parser. However, preload scanner could pick these up, it just doesn't yet, whereas scripts included by executable code can never be preloaded. Thanks to Yoav Weiss who corrected me in the comments.

async和defer将在HTML解析期间下载文件。两者都不会中断解析器。

带有async属性的脚本一旦下载就会被执行。而具有defer属性的脚本将在完成DOM解析后执行。 使用async加载的脚本不能保证任何顺序。而使用defer属性加载的脚本则保持它们在DOM上出现的顺序。

当脚本不依赖任何东西时,使用<script async>。 当脚本依赖时,使用<script defer>。

最好的解决方案是在正文的底部添加<script>。不存在阻塞或渲染的问题。

Default - By default, as soon as the browser sees a script tag it downloads the file and then executes the script file. The script files are executed in the order of their occurrence. async - The browser will download the script file and continue parsing HTML parallelly until the file is downloaded. The file is executed as soon as it is downloaded. defer - The browser will download the script and do HTML parsing at the same time. After parsing is done, the script files are executed in the order of their occurrence.

注意: 在defer中,js文件按照它们在HTML文件中出现的顺序执行,而在async属性的情况下,脚本文件按照下载时间的顺序执行。

看起来defer和async的行为是依赖于浏览器的,至少是在执行阶段。说明“defer”仅适用于外部脚本。我假设async遵循相同的模式。

在IE 11及以下版本中,顺序是这样的:

异步(可以在页面加载时部分执行) 无(可以在页面加载时执行) 延迟(在页面加载后执行,所有延迟在文件中的位置顺序)

在Edge, Webkit等中,async属性似乎要么被忽略,要么被放在末尾:

data-page - speed-no-defer(在加载页面时,在任何其他脚本之前执行) 无(可以在页面加载时执行) 延迟(等待DOM加载,所有延迟在文件中的位置顺序) async(似乎等待DOM加载)

在较新的浏览器中,data-pagespeed-no-defer属性在任何其他外部脚本之前运行。这适用于不依赖于DOM的脚本。

注意:当您需要明确外部脚本的执行顺序时,请使用defer。这告诉浏览器按照在文件中的位置顺序执行所有延迟脚本。

旁白:外部javascript的大小在加载时确实很重要……但对执行顺序没有影响。

如果您担心脚本的性能,那么您可能需要考虑缩小或使用XMLHttpRequest动态加载它们。