阅读 558

【性能优化实践】优化打包策略提升页面加载速度

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.jsstatic/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. 写在最后

需要指出,性能优化也许有一些“基本准则”,但绝对没有银弹。无论是多么“基础与通用”的优化手段,亦或是多么“复杂而有针对性”的优化手段,都是在解决特定的具体问题。因此,解决性能问题往往都是从实际出发,通过“排查问题 --> 分析诊断 --> 实施优化 --> 验证效果”这样一条不断循环的路径来开展的。

同时,提升性能的其中一个目的就是更好的用户体验。用户体验往往是一个宽泛的概念,涉及方方面面。相对应的,性能优化也不能只死盯着某个“指标”,更应该理解其背后对产品与用户的意义。从问题出发,拿数据量化,找解决方案。

在实际环境下,面对有限的资源和各种限制,创造最大的价值。性能优化更是如此。

参考资料

关注下面的标签,发现更多相似文章
评论