前端性能的几个基础指标

时间 2019-11-10

标签前端性能几个基础指标栏目系统性能繁體版

原文原文链接

2018.3.1更：

有赞·微商城(base杭州)部门招前端啦，最近的前端hc有十多个，跪求大佬扔简历，我直接进行内推实时反馈进度，有兴趣的邮件 lvdada#youzan.com，或直接微信勾搭我 wsldd225 了解跟多javascript

有赞开源组件库·zanUIcss

前端性能的几个基础指标

先开门见山的罗列前端性能相关的几个基础指标名词。html

白屏时间
首屏时间
用户可操做时间
页面总下载时间

为什么会选择这几个时间节点以及各自的含义能够参考这篇文章七天打造前端性能监控系统
另外本文搜集性能相关数据是用了高级浏览器的Performance Api,你们能够参考这篇文章先行了解初探erformancep前端

正文

上图看了有和感觉？当页面刷新后可视区域长时间停留在白屏状态，当一个阶段后页面忽然所有刷出，而不是咱们追崇的逐步加载显示的状态。java

上图显示的是视口上部分已经展现，可是因为某种缘由页面下部分的视图被阻塞，一段时间后，剩余页面忽然刷出，也不符合页面逐步显示的体验。jquery

上图的现象是可交互的区域已经出如今视口中了，用户也已经在可点击的地方进行狂点，可是图片资源没有加载完可致使点击事件没有绑定，点击无效。这种交互体验也是不能容忍的。git

上面几个例子正好能够带出两个性能指标 `白屏时间` 和 `用户可操做时间`

白屏时间：用户从打开页面开始到有页面开始呈现为止。
用户可操做时间：用户能够进行正常的事件输入交互操做。github

接下来咱们经过Performance Api看看如何获得这两个指标的数据。web

http://www.w3.org/TR/navigati...
上图来自官方，从左到右表明了浏览器打开一个页面内部的一系列状态。左边红线表明的是网络传输层面的过程，这篇文章不过多讲述，右边红线表明了服务器传输回字节后浏览器的各类事件状态，也就是上图中的responseEnd以后。这个阶段包含了浏览器对文档的解析，dom树构建，布局，绘制等等。下面详细说明。api

在浏览器console中输入performance.timing，返回的各字节跟上图performance流程的各状态一一对应，并返回时间。

上图简单说明了一下performance timing api在几个流程下所表明的含义。至于为什么到达domInteractive状态时表明了Dom tree 构建完成我在下文还会解释到。

上图演示了一个页面加载时Chrome的调试工具中的Network会显示两条竖线，一蓝一红，蓝的表明document触发了domContentLoaded事件，红线表明了document触发了load事件。

理一理

咱们说到了当document到达domInteractive状态时表明了dom树的构建完成，也表明了能够绑定事件，即用户可交互时间已经到达，也表明了触发domContentLoaded事件，也即表明Chrome调试中蓝线的出现。
但这一连串因果又是从何获得的呢？

深剖why

上图说明在浏览器拿到文档首字节以后，即上文提到的responseEnd以后。浏览器将html解析并构建成DOM tree，并同时将css解析成CSSOM。在没有js的参与下，这个过程是同步的。

但一旦有js的参与，这个平衡就被破坏了。

同步的javascript能够改写文档在任何节点，所以DOMtree 一旦碰上script标签（同步）就会中止构建。script也会阻塞img资源的下载。
javascript能查询dom对象的可被计算的样式，CSSOM构建完才能轮到js的执行（仅位于script以前的css文件（内嵌、外链）才会阻塞js的执行，若样式文件在script以后，则此样式文件不会阻塞script）

这两点的解释说明能够看这里和这里

因为上面两个缘由，致使html的解析构建与css构建成CSSOM有了依赖关系

而后咱们看一下官方文档

        这里解释了document到达interactive状态所表明的含义，我先将其中一块信息隐藏。根据这个说明，当文档解析完成可是，一些例如图片这些资源尚未加载完成的状况下，document到达interactive状态，而且触发DOMContentLoaded事件触发。下面来看一个实例。

        结合上面的深剖，CSSOM构建阻塞了js的执行，因此在这幅图中js早已加载完，仍是要等到css的下载完成才能执行，而js的被阻塞，又致使了html文档的解析DOM树的构建。再根据官方的说明，dom树的构建完成才意味着interactive到达，意味着蓝线的出现。
        但咱们再看下官方说明的原话。

        是的，刚刚被我遮盖掉的是stylesheets样式表。这里又明确提到了不等stylesheets样式表下载完成，一旦html解析dom树构建完document就立马到达interactive状态。这不是跟咱们刚刚的例子相反了吗？
再看个例子

        这个例子蓝线停在了css文件下载完成以前，说明也验证了后一种说法。那究竟是哪一个对？
        答案固然是都对，咱们在最以前就说明了，在没有js参与的状况下，html的解析DOM树的构建和CSSOM的构建是平行的，谁也不碍着谁，interactive状态的变动直接取决于html的解析完成度，因此在这种状况下，不等css加载完，html一旦解析完成，document状态立马变动为interactive。第二个例子是没有js引入的。

深剖小结

上述的引入的js只是同步的。也就是不带defer 或 async的script标签。一旦引入了带defer或async的script标签，js、css的依赖关系又变了。这里就不详谈了，能够看一篇外文Deciphering the Critical Rendering Path
或者个人翻译版本个人翻译

总结

如今咱们再来看一下domContentLoaded和load事件。如今应该能清楚为什么domContentLoaded事件触发表明了用户可交互事件，以及

$(function () {

})

jquery中的这个写法就是基于这个事件。

最后，咱们回头看下开头指出的衡量页面性能的四个基础指标，以及各自的求法。

白屏时间：除了可使用现成的performance api，咱们还能够在head之间头尾插入两个script计算时间差

<head>
<script>
var t = new Date().getTime();
</script>
<link src="">
<link src="">
<link src="">

<script>
tNow = new Date().getTime() - t;
</script>
</head>

这样作可行的原理：第一个script不受css阻塞，最后的script受css阻塞，会等到样式都下载完才执行，执行完后即是body的解析，以后是dom tree构建，布局，绘制而后呈如今屏幕上。

用户可交互时间：根据performance api在根据以前的讲述，可得domContentLoadedEventEnd - navigationStart

参考：
performance api
关键路径
 performance api github
分析关键呈现路径性能
 初识performance
jscss顺序
 S 和 CSS 的位置对其余资源加载顺序的影响
 7 天打造前端性能监控系统
完！

原创文章转载请注明出处！

前端性能的几个基础指标

前端性能的几个基础指标

正文

上面几个例子正好能够带出两个性能指标 白屏时间 和 用户可操做时间

理一理

深剖why

深剖小结

总结

上面几个例子正好能够带出两个性能指标 `白屏时间` 和 `用户可操做时间`