前端优化-其五 javascript优化

随着现代web技术越来越成熟，浮现出了一批批优秀而又成熟的框架。驱动这些框架产生的原因是我们的web需要解决越来越复杂的需求。随之而来的便是越来越复杂的代码，越来越大的代码文件。

javascript 是最昂贵的资源

由于web的特殊性，我们总是习惯的将文件大小看得很敏感。也有优秀的技术把我们的代码文件压缩到很小：通过工具压缩后的代码，再结合gzip技术往往可以把代码文件压缩到原大小的十几分一。这当然很棒，我们节省了大量的带宽。

反过来想，如果我们传输了150k的js文件，这很常见。代表着unGzip之后这些代码将有750kb~1M左右。

在篇二中，我们努力的优化了页面的首屏渲染，尽快的让浏览器看起来不是一片空白，而是有内容画在上面。但是在js解析完成之前，我们努力优化得到的只是一个不可交互的 ‘网页’ 而已。这看起来并不完美。

随着这几年组件化开发的流行，在相关js库解析完成之前，我们的组件系统可能并没有办法成功的渲染出来。这看起来十分不完美。（可以通过预渲染和服务器渲染来解决）

javascript好可怕

从dom解析到script标签时，便会暂停dom树的构建并执行，这期间可能会发生：

• 发起请求（包括dns,tcp,http的），解压缩(unGzip)
• 解析和编译JS的顶级函数
• 执行脚本

在最后一步 执行脚本 完成之前，我们的网页几乎是不可交互的。script的执行是发生在主线程上，这意味着他会阻止ui。uhm，就是说我们连下拉一下滚动条都做不到了，真过分。如果你的script复杂无比，花费了1分钟还没有执行完成，浏览器可能就会漰溃了。

有一个小例子

我截取了一个不大知名的网站的加载性能图，执行机器是一台普通的办公用pc。黄色的是script执行时间，占据了1200ms之多，这个网站的的脚本文件大小是170k左右（文件大小不代表执行时间）。数据看起来非常的夸张，如果不需要执行这些脚本，我们可能只需要220ms左右就完成了网页的加载。

需要这么多脚本吗

好像并不是很需要阿？？？是哦，是的吧。

怎么去优化它

解析/执行js脚本这花费时间，或许我们可以减少要执行的js脚本、减少被执行脚本的复杂度、分批次去执行脚本？好像都可以的样子。

• 通过代码分割工具，只使用尽量少的代码。你可以通过webpack来实现它
• 懒加载非关键的代码，这可以通过异步，也可以是把脚本直接扔到模板里。
• 删除不使用的代码，使用chrome devtools代码覆盖率来删除不使用的代码详见
• 使用 closure Complier。幸运的是，很多js压缩工具里已经集成了它。详见
• 推迟复杂代码块的执行，使用setTimeout requestAnimationFrame等。

最后

以上测试都来自pc，移动设备往往代表着更差的cpu计算和更差的网络。应该重视javascript执行所带来的性能成本。