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

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

在网站加载速度方面

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

使用<script defer src=…

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

使用<script async src=…

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

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

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


当前回答

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动态加载它们。

面对同样的问题,现在清楚地了解两者将如何工作。希望这个参考链接会有帮助…

异步

当您将async属性添加到脚本标记时,将发生以下情况。

<script src="myfile1.js" async></script>
<script src="myfile2.js" async></script>

发出并行请求来获取文件。 继续解析文档,就像它从未被打断过一样。 文件下载后立即执行各个脚本。

推迟

延迟与异步非常相似,但有一个主要区别。下面是浏览器遇到带有defer属性的脚本时会发生的情况。

<script src="myfile1.js" defer></script>
<script src="myfile2.js" 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属性的情况下,脚本文件按照下载时间的顺序执行。

渲染引擎经过几个步骤,直到它在屏幕上绘制任何东西。

它是这样的:

Converting HTML bytes to characters depending on encoding we set to the document; Tokens are created according to characters. Tokens mean analyze characters and specify opening tangs and nested tags; From tokens separated nodes are created. they are objects and according to information delivered from tokenization process, engine creates objects which includes all necessary information about each node; after that DOM is created. DOM is tree data structure and represents whole hierarchy and information about relationship and specification of tags;

CSS也是同样的过程。CSS渲染引擎为CSS创建不同的/分离的数据结构,但它被称为CSSOM (CSS对象模型)

Browser只适用于对象模型,所以它需要知道所有关于DOM和CSSDOM的信息。

下一步是以某种方式组合DOM和CSSOM。因为没有CSSOM浏览器不知道在渲染过程中如何样式化每个元素。

以上所有信息意味着,你在html (javascript, css)浏览器中提供的任何东西都会暂停DOM构建过程。如果你熟悉事件循环,有一个简单的规则事件循环如何执行任务:

执行宏任务; 执行微任务; 呈现;

所以当你提供Javascript文件时,浏览器不知道JS代码要做什么,并停止所有的DOM构造过程,Javascript解释器开始解析和执行Javascript代码。

即使你在body标签的末尾提供Javascript,浏览器也会进行HTML和CSS的所有上述步骤,但渲染除外。它会找到Script标签并停止,直到JS完成。

但是HTML为脚本标记提供了两个额外的选项:async和defer。

Async -意思是当代码被下载时执行,并且在下载过程中不阻塞DOM构造。

延迟——意思是在代码下载和浏览器完成DOM构造和渲染过程后执行。

我认为杰克·阿奇博尔德在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.