TL;DR
- 可以考虑基于HTTP Cache来定义打包维度，将Cache周期相同的script尽量打包在一起，最大限度利用Cache；
- 合并零散的小脚本，避免触发浏览器并发请求限制后，资源请求串行，TTFB叠加等待时间；
- 注意打包后的资源依赖与资源引入顺序。
1. 引言
性能优化涵盖的范围非常之广，其中包含的知识也非常繁杂。从加载性能到渲染性能、运行时性能，每个点都有非常多可以学习与实践的知识。
优化问题包含方方面面，优化手段也依场景和具体问题而定。因此，本文并不是一个泛而全的概览文章，而是以之前的一次对于业务产品的简单优化（主要是DOMContentLoaded时间）为例，介绍了如何使用Chrome Dev Tools来分析问题，使用一些策略来缩短DOMContentLoaded的时间，提高加载速度。
2. DOMContentLoaded事件
W3C将页面加载分为了许多阶段， DOMContentLoaded（以下简称DCL）类似的有一些 DOM readState ，它们都会标识页面的加载状态与所处的阶段。我们接触最多的也就是 readState 中的 interactive、complete（或load事件）以及DCL事件
简单了解一下它们。浏览器会基于HTML内容来构建DOM，并基于CSS构建CSSOM。两者构建完成后，会合并为Render Tree。当DOM构建完毕后， document.readyState 状态会变为 interactive 。
Render Tree构建完成就会进入到我们非常熟悉的 Layout –>> Paint –>> Composite 管道。
但是当页面包含Javascript时，这个过程会有些区别。
根据HTML5 spec，由于在Javascript中可以访问DOM，因此当浏览器解析页面遇到Javascript后会阻塞 DOM 的解析；于此同时，为避免CSS与Javascript之间的竞态，CSSOM的构建会阻塞 Javascript 脚本的执行。不过有一个例外，如果将脚本设置为async，会有一个区别，DCL的触发不需要等待async的脚本被执行。
也就是：
- 当浏览器完成对于document的解析（parse）时，文档状态就会被标记为
interactive。即 "DOM tree is ready"。 - 当所有普通（既不是defer也不是async）与defer的脚本被执行，并且已经没有任何阻塞脚本的样式时，浏览器就会触发
DOMContentLoaded事件。即 "CSSOM is ready"。
或者将上面的部分精简一下：
DOM construction can’t proceed until JavaScript is executed, and JavaScript can’t proceed until CSSOM is available. [1]
3. 排查问题
下面就可以通过Chrome Dev Tools来分析问题。为了内容精简，以下截图取了在slow 3G 无缓存模式下的访问情况，为了保持和线上环境类似（还原浏览器的同源最大请求并发），在本地搭建对应的服务器放置静态资源。wifi情况下，各个时间点大致等比缩短8~9倍。
首先看一个整体的waterfall
在最下面可以看到 DCL 为 17.00s（slow 3G）。
p.s. 页面load时间也很长。主要因为业务膨胀后，页面包含过多资源，没有使用一些懒加载与异步渲染技术，这部分也存在很多优化空间，但由于篇幅不在本文中讨论内。
页面里有一个很明显的请求block了DCL —— common.js。那么common.js是什么呢？它其实就是项目中一些通用脚本文件的打包合并。
由于common.js为同步脚本，因此等到它其下载并执行完毕后，才会触发DCL。而与此对应的，其他各个脚本的时间线与其有很大差距。具体来看common.js的Timing pharse，耗时11.44s，其中download花费 7.12s。
4. 分析诊断
download过长最直接的原因就是文件太大。common.js的打包合并包含了下面的内容
'pkg/common.js': [
'static/js/bridge.js', // 业务基础库
'static/js/zepto.min.js', // 第三方库
'static/js/zepto.touch.min.js', // 第三方库
'static/js/bluebird.core.min.js', // 第三方库
'static/js/link.interceptor.js', // 业务基础库
'static/js/global.js', // 业务基础库
'static/js/felog.js', // 业务基础库
'widget/utils/*.js' // 业务工具组件
]
这里，我们发现这么打包会存在下面几个问题：
4.1. 文件大小
download过长最直接的原因：文件过大。
将这些资源全部打包在一起导致common.js较大，原文件161KB，gzip 之后为52.5KB，单点阻塞了关键渲染路径。你也可以在 audits 中的Critical Request Chains部分发现common.js是瓶颈。
4.2. HTTP Cache
zepto/bluebird这种第三方库属于非常稳定的资源，几乎不会改动。虽然代码量较多，但是通过HTTP Cache可以有效避免重复下载。同时，上线新版后，为了避免一些文件走 HTTP Cache，我们会给静态资源加上 md5。
然而，当这些稳定的第三方库与一些其他文件打包后，会因为该打包中某些文件的局部变动导致合并打包后的hash变化而缓存失效。
例如，其中bridge.js与/utils/*.js容易随着版本上线迭代，迭代后打包导致common的hash变化，HTTP Cache失效，zepto/bluebird等较大的资源虽然未更改，但由于打包在了一起，仍需要重新下载。每次上线新版本后，一些加载的性能数据表现都会显著下降，其中一部分原因在于此。
5. 实施优化手段
结合上面分析的问题，可以进行一些简单而有效的优化。
5.1. 拆包
考虑将文件的打包合并按照文件的更新频率进行划分。这样既可以有效缩减common.js的大小，也可以基于不同类型的资源，更好利用HTTP Cache。
例如：
-
将基本不会变动的文件打包为 lib.js，主要为一些第三方库，这类文件几乎不会改动，非常稳定。
-
将项目依赖的最基础js打包为common.js，例如本文中的global.js、link.interceptor.js，项目中的所有部分都需要它们，同时也是项目特有的，相较上一部分的lib会有一定量的开发与改动，但是更新间隔可能会有几个版本。
-
将项目中变动较为频繁的工具库打包为util.js，理论上其中工具由于不作为基础运行的依赖，是可以异步加载的。这部分代码是三者之中变动最为频繁的。
'pkg/util.js': [
'widget/utils/*.js'
],
'pkg/common.js': [
'static/js/link.interceptor.js',
'static/js/global.js',
'static/js/felog.js'
],
'pkg/lib.js': [
'static/js/zepto.min.js',
'static/js/zepto.touch.min.js',
'static/js/bluebird.core.min.js'
]
5.2 Quene Delay
但是在拆分后DCL时间几乎没有减少。
这里就不得不提到打包的初衷之一：减少并发。我们将common.js拆分为三个部分后，触碰到了同域TCP连接数限制，图中的这四个资源被chrome放入了队列（图中白色长条）。
Queueing. The browser queues requests when:
- There are higher priority requests.
- There are already six TCP (Chrome) connections open for this origin, which is the limit. Applies to HTTP/1.0 and HTTP/1.1 only.
- The browser is briefly allocating space in the disk cache
我们打包合并资源一定程度上也是为了减少TCP round trip，同时尽量规避同域下的请求并发数量限制。因此在common.js拆分时，也要注意不宜分得过细，否则过犹不及，忘了初衷。
从network waterfall中也很容易发现，大部分资源由于size较小，其下载时间其实非常短，耗时主要是在TTFB（Time To First Byte），可以粗略理解为在等待服务器返回数据（图中表现出来就是绿色较多）。所以除了打包项目依赖的lib.js/common.js/util.js外，还可以考虑将部分依赖的组件脚本进行打包合并，
像上图中这四个脚本的耗时都在在TTFB上，而且在同一个CDN上，可以通过打包减小不必要的并发。将首屏依赖的关键组件进行打包：
'pkg/util.js': [
'widget/utils/*.js'
],
'pkg/common.js': [
'static/js/bridge.js',
'static/js/link.interceptor.js',
'static/js/global.js',
'static/js/felog.js'
],
'pkg/lib.js': [
'static/js/zepto.min.js',
'static/js/zepto.touch.min.js',
'static/js/bluebird.core.min.js'
],
'pkg/homewgt.js': [
'widget/home/**.js',
'widget/player/*.js',
]
优化后的DCL变为了11.20s。
5.3 资源引入顺序
注意，一些打包工具会自动分析文件依赖关系，文件打包后会同时替换资源路径。例如：在HTML中，引用了 static/js/zepto.min.js 和 static/js/bluebird.core.min.js 两个资源，在打包后构建工具会将HTML中的引用自动替换为 lib.js 。因此需要注意打包后的资源加载顺序。
例如，原HTML中的资源顺序
<script type="text/javascript" src="//your.cdn.com/static/js/bridge.js"></script>
<script type="text/javascript" src="//your.cdn.com/static/js/zepto.min.js"></script>
<script type="text/javascript" src="//your.cdn.com/static/js/bluebird.core.min.js"></script>
<script type="text/javascript" src="//your.cdn.com/static/js/global.js"></script>
其中 global.js 依赖于 zepto.min.js，这个在目前看来没有问题。但是由于打包合并，构建工具会自动替换脚本文件名。由于 bridge.js 的位置，在打包后common.js的引入顺序先于lib.js。这就导致 global.js 先于 zepto.min.js 引入与执行，出现错误。
对此，在不影响原有依赖的情况下，可以调整脚本顺序
<script type="text/javascript" src="//your.cdn.com/static/js/zepto.min.js"></script>
<script type="text/javascript" src="//your.cdn.com/static/js/bluebird.core.min.js"></script>
<script type="text/javascript" src="//your.cdn.com/static/js/bridge.js"></script>
<script type="text/javascript" src="//your.cdn.com/static/js/global.js"></script>
输出的结果如下：
6. 验证效果
最终在无缓存的slow 3G下DCL时间11.19s，相比最初的17.00s，降低34%。（wifi情况下降比例相同，时间大致同比为1/8~1/9，接近1s）。同时，相较于之前，一些静态资源能够更好地去利用HTTP Cache，节省带宽，降低每次新版上线后用户访问站点的静态资源下载量。
7. 写在最后
需要指出，性能优化也许有一些“基本准则”，但绝对没有银弹。无论是多么“基础与通用”的优化手段，亦或是多么“复杂而有针对性”的优化手段，都是在解决特定的具体问题。因此，解决性能问题往往都是从实际出发，通过“排查问题 --> 分析诊断 --> 实施优化 --> 验证效果”这样一条不断循环的路径来开展的。
同时，提升性能的其中一个目的就是更好的用户体验。用户体验往往是一个宽泛的概念，涉及方方面面。相对应的，性能优化也不能只死盯着某个“指标”，更应该理解其背后对产品与用户的意义。从问题出发，拿数据量化，找解决方案。
在实际环境下，面对有限的资源和各种限制，创造最大的价值。性能优化更是如此。
