第三方脚本标签中异步与延迟的性能影响

Question

当考虑到下载后的脚本执行及其对页面性能的影响时，async和defer的使用有何不同？

异步

• 在执行时阻止页面解析
• 一旦可用就立即执行

推迟

< li >在页面完成解析后执行 < li >在< code>DOMContentLoaded事件之前执行 < li >尊重脚本顺序

对我来说，deer的影响似乎较低，因为下载后的执行发生在页面解析之后，而async脚本在下载后执行会阻止解析。但是为什么我经常看到async和deer一起使用，后者只是后备？异步似乎只是现代的方式，但我不明白为什么。如果async和deer都适用于我的案例，那么deer不是会降低性能影响吗？还是异步执行脚本的事实战胜了延迟，即使async阻止了解析？

Answer 1

在考虑下载后的脚本执行及其对页面性能的影响时，异步和延迟的使用有何不同？

你下一段最多解释一下。我甚至不知道async可以阻塞。这么好的研究:)

但是为什么我经常看到async和defer一起使用，而后者只是一个后备呢？

是的。看规格:

https://www.w3.org/TR/2011/WD-html5-20110525/scripting-1.html#attr-脚本异步

即使指定了async属性，也可以指定defer属性，以使仅支持defer(而非async)的传统Web浏览器退回到defer行为，而不是默认的同步阻塞行为。

@ty https://stackoverflow.com/a/13821238/7387397

如果异步和延迟都适用于我的案例，那么延迟对性能的影响会不会降低？或者，异步执行脚本的事实是对延迟的胜利，即使异步阻止解析？

取决于剧本。如果是一个分析脚本，我个人更喜欢< code>asnyc，因为你可以在网站上获得更好的统计数据。它也不依赖于DOM。

当它是聊天脚本或类似脚本时。我将选择聊天是否更需要我的主脚本。如果您的网站主要在没有javascript的情况下工作，您可以给出一个“更快”的TTI。请记住，当您有很多javascript时，交互式时间（TTI）也可能对您不利。

Ads和其他脚本可以使用＜code＞defer＜code＞加载，不需要立即执行。

请记住，这是个人经验。这实际上主要取决于脚本和您的网站。对于性能，没有黄金法则:)