关于前端:我对JS延迟异步脚本的思考

9次阅读

共计 1879 个字符,预计需要花费 5 分钟才能阅读完成。

对于对提早脚本的思考

  • asyncdefer 属性的脚本,置信大家都据说过,然而他的真正执行细节是什么样子的?很少有文章认真钻研它, 可能不太有人重视细节, 但其实真正有技术含量的工作和我的项目, 对于性能要求极高, 那么细节就很重要了. 须要一直的试验自我尝试
  • 最近几个月,我始终在钻研一些技术,例如linux, 操作系统, 算法等, 预计要继续学习到今年年底。红宝书第四版进去后,我也是花了很多工夫去看。对于提早脚本,本人也是做了一个试验,写下了这篇总结

什么是提早脚本?

  • script标签,带 asyncdefer属性等,通过 document.createElement('script') 创立并且没有指定 script.async=false 的脚本默认为 异步提早 脚本(必须为非内联脚本), 如下所示:
<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
</head>

<body>

</body>
<script src="./async1.js" async></script>
<script src="./async2.js" async></script>
<script src="./defer1.js" defer></script>
<script src="./defer2.js" defer></script>
<script src="./common1.js"></script>
<script src="./common2.js"></script>
<script src="./common3.js"></script>

</html>
  • 以上 7 个脚本文件, 其中 common 结尾为非异步提早脚本, 其余的都指定了提早脚本的模式,分为 asyncdefer两种

通过 document.createElement 创立的标签插入默认为 async 模式

开始试验

  • 我一共写了 2 个 async 和 2 个 defer 标签, 其它的都是一般标签. 其中 async1.js 外面有 4000 行代码, 其它都是一个 console.log 而已
  • 第一次试验后果:

  • 再次刷新页面(留神我曾经禁用了浏览器缓存), 后果为:

  • 再次刷新, 发现 async 执行机会和程序不确定,然而能确定 defer 必定在 async 之后执行。

起因在于:async是通知浏览器, 能够不用等到它下载解析完后再加载页面, 也不必等它执行完后再执行其余脚本, 俗称 异步执行脚本

看下载执行机会和打印后果的比照

  • 打印后果:

  • 对应的下载执行机会

  • 从下面看,下载机会 async 和一般模式都是同样并行下载, 只有 defer 是最初才下载 (http1.1 有并发数量限度, 可是这里并不是并发限度,当我删除common 的援用后, 我发现 defer 永远都是最初下载的)

  • asyncdefer 两种模式,区别在于:

    • async是通知浏览器, 它不会操作 dom, 能够不用等到它下载解析完后再加载页面, 也不必等它执行完后再执行其余脚本, 俗称 异步执行脚本 , 多个async 无奈保障他们的执行程序, 例如 async1async2无奈按程序执行
    • defer是在解析到完结到 </html> 标签后才会执行, 俗称 推延执行脚本 , 多个defer 能够按程序执行, 例如 defer1defer2能够按程序执行(实际上也不保障程序执行)
    • 解析到 script 标签后,async是间接下载
    • 解析到 script 标签后,defer是最初下载
  • 相同点:

    • 多个 async 或者 defer 标签实际上都不能保障程序执行
    • 都不会阻塞解析其余 script 标签内容的解析和页面渲染
    • 他们都会在浏览器 load 事件前执行,然而不保障是在 DomContentLoad 事件前还是后执行
    • defer必定在 async 前面执行,从我的试验后果和书上对它们对解析来看

影响多个异步脚本的执行程序因素

  • 脚本文件大小
  • 网络传输因素

非凡状况

  • 当所有的脚本文件都很小很小的时候, 后果会在很大概率稳固在

应用的留神点

  • 异步推延脚本的执行程序并不稳固, 所有尽量只有一个
  • 应用异步推延脚本时, 应该思考什么场景才应用, 而不是滥用它

写在最初

  • 纸上得来终觉浅, 欲知此事要躬行, 我写得也不肯定对, 如果你有问题或者更好的答案能够在上面参加探讨, 我始终认为有争议和拥护的声音是坏事
  • 另外你如果感觉写得不错对你有帮忙, 能够帮忙点个 在看 / 赞 / 关注.
  • 关注 前端巅峰 公众号后回复:加群 , 即可加群获取3800G 收费前端学习视频资源
正文完
 0