前端性能监控

1.什么是前端

对于网站来说，通常是指网站的前台部分，也就是Web应用中用户可以看得见碰得着的东西。

 

2.为什么要做前端性能监控

根据《高性能网站建设指南》上的数据，整个页面的加载可以划分为3大块：网络时间、后端时间、前端时间，发生在网络和后端的时间占到整体加载时间的10%和20%，而前端资源加载时间占到整体加载时间的70%-80%。

前端资源加载是否快速对性能影响是最大的，这里面资源的加载顺序，并发数量，都有很多的工作可做：比如，如果发现 CSS 加载之前的阻塞时间很长，那很可能是资源加载顺序不合理，这必然会导致浏览器渲染延后。

 

3.前端性能监控指标

• 白屏时间：用户从打开页面开始到页面开始有东西呈现为止；

• 首屏时间：用户浏览器首屏内所有内容都呈现出来所花费的时间；

• 用户可交互时间：用户可以进行正常的点击、输入等操作，默认可以统计domready时间，因为通常会在这时候绑定事件操作；

• 总下载时间：页面所有资源都加载完成并呈现出来所花的时间，即页面 onload 的时间。

 

确定统计起点 

需要在用户输入 URL 或者点击链接的时候就开始统计，因为这样才能衡量用户的等待时间。高端浏览器Navigation Timing接口；普通浏览器通过 cookie 记录时间戳的方式来统计，需要注意的是 Cookie 方式只能统计到站内跳转的数据。

统计白屏时间

白屏时间是用户首次看到内容的时间，也叫做首次渲染时间，chrome 高版本有 firstPaintTime 接口来获取这个耗时，但大部分浏览器并不支持，必须想其他办法来监测。仔细观察 WebPagetest 视图分析发现，白屏时间出现在头部外链资源加载完附近，因为浏览器只有加载并解析完头部资源才会真正渲染页面。基于此可以通过获取头部资源加载完的时刻来近似统计白屏时间。尽管并不精确，但却考虑了影响白屏的主要因素：首字节时间和头部资源加载时间。

如何统计头部资源加载呢？发现头部内嵌的JS通常需等待前面的 JS\CSS 加载完才会执行，是不是可以在浏览器head内底部加一句JS统计头部资源加载结束点呢？可以通过一个简单的示例进行测试：

 

统计的头部加载时间正好跟头部资源下载时间相近，而且换成一个执行时间很长的 JS 也会等到 JS 执行完才统计。说明此方法是可行的(具体原因可查看浏览器渲染原理及 JS 单线程相关介绍)。

统计首屏时间

首屏时间的统计比较复杂，因为涉及图片等多种元素及异步渲染等方式。观察加载视图可发现，影响首屏的主要因素的图片的加载。通过统计首屏内图片的加载时间便可以获取首屏渲染完成的时间。统计流程如下：

首屏位置调用 API 开始统计 -> 绑定首屏内所有图片的 load 事件 -> 页面加载完后判断图片是否在首屏内，找出加载最慢的一张 -> 首屏时间。

这是同步加载情况下的简单统计逻辑，另外需要注意的几点：

· 页面存在 iframe的情况下也需要判断加载时间；

· gif图片在 IE 上可能重复触发 load事件需排除；

· 异步渲染的情况下应在异步获取数据插入之后再计算首屏；

· css重要背景图片可以通过 JS请求图片 url来统计(浏览器不会重复加载)；

· 没有图片则以统计 JS执行时间为首屏，即认为文字出现时间。

统计用户可操作和总下载

用户可操作默认可以统计domready时间，因为通常会在这时候绑定事件操作。对于使用了模块化异步加载的 JS 可以在代码中去主动标记重要 JS 的加载时间，这也是产品指标的统计方式。

总下载时间默认可以统计onload时间，这样可以统计同步加载的资源全部加载完的耗时。如果页面中存在很多异步渲染，可以将异步渲染全部完成的时间作为总下载时间。

 

4.性能监控工具

由于收集数据的方式和目标不一样，前端性能监控主要分为非侵入式式和侵入式两种。

类型

优点

缺点

示例

非侵入式

指标齐全、客户端主动监测、竞品监控

无法知道性能影响用户数、采样少容易失真、无法检测复杂应用与细分功能

Yslow、Pagespeed、Dynatrace、Fiddler、webpagetest（线上）、gtmetrix（线上）

侵入式

真实海量用户数据、能监控复杂应用与业务功能、用户点击与区域渲染

需插入脚本统计、网络指标不全、无法监控竞品

Navigation Timing API、Resource Timing API

对于统计脚本需要满足两个条件：

(1)避免对业务代码的入侵；

(2)不影响被测量的页面的性能；

4.1非侵入式

（1）pagespeed

是谷歌开发的分析和优化网页的工具，可以作为浏览器插件使用。工具基于一系列优化规则对网站进行检测，对于未通过的规则会给出详细的建议。

 

点击开始分析，稍后就会给出分析结果

 

（2）Yslow

是Yahoo发布的一款基于FireFox的插件。推荐使用gtmetrix网站同时查看多个分析工具的结果。

 

（3）WebPagetest

WebPageTest 是一款非常优秀的网页前端性能测试工具,已开源。可以使用在线版，也可以自己搭建。国内也有利用 WebPagetest 搭建的性能测试平台，推荐使用阿里测 (以下示例使用阿里测进行测试)。

使用 WebPagetest，可以详细掌握网站加载过程中的瀑布流、性能得分、元素分布、视图分析等数据。其中比较直观的视图分析功能可以直接看到页面加载各个阶段的截屏:

 

4.2侵入式

（1）Navigation Timing API

监测主文档加载速度，该API提供一种简单的获取页面被导航或被加载时的时间及相关信息的方法。目前为止，在Internet Explorer 9、Google Chrome以及Firefox nightly Builds浏览器中对该API提供支持。

 

一个performance对象的完整结构如下图所示：

 

 

memory字段代表JavaScript对内存的占用，是在Chrome中添加的一个非标准属性。
   

jsHeapSizeLimit: 内存大小限制；totalJSHeapSize: 可使用的内存；
usedJSHeapSize: JS对象(包括V8引擎内部对象)占用的内存，不能大于totalJSHeapSize，如果大于，有可能出现了内存泄漏。

navigation字段统计的是一些网页导航相关的数据：

1. redirectCount:重定向的数量（只读），但是这个接口有同源策略限制，即仅能检测同源的重定向；

2. type 返回值应该是0,1,2 中的一个。分别对应三个枚举值:

 0 : TYPE_NAVIGATE (用户通过常规导航方式访问页面，比如点一个链接，或者一般的get方式)

 1 : TYPE_RELOAD (用户通过刷新，包括JS调用刷新接口等方式访问页面)

 2 : TYPE_BACK_FORWARD (用户通过后退按钮访问本页面)

最重要的是timing字段的统计数据，它包含了网络、解析等一系列的时间数据。

timing的整体结构如下图所示：

 

各字段的含义如下：

· startTime：有些浏览器实现为navigationStart，代表浏览器开始unload前一个页面文档的开始时间节点。比当前正在浏览baidu.com，在地址栏输入google.com并回车，浏览器的执行动作依次为：unload当前文档（即baidu.com）->请求下一文档（即google.com）。navigationStart的值便是触发unload当前文档的时间节点。

如果当前文档为空，则navigationStart的值等于fetchStart。

· redirectStart和redirectEnd：如果页面是由redirect而来，则redirectStart和redirectEnd分别代表redirect开始和结束的时间节点。

· unloadEventStart和unloadEventEnd：如果前一个文档和请求的文档是同一个域的，则unloadEventStart和unloadEventEnd分别代表浏览器unload前一个文档的开始和结束时间节点。否则两者都等于0；

· fetchStart是指在浏览器发起任何请求之前的时间值。在fetchStart和domainLookupStart之间，浏览器会检查当前文档的缓存。

· domainLookupStart和domainLookupEnd分别代表DNS查询的开始和结束时间节点。如果浏览器没有进行DNS查询（比如使用了cache），则两者的值都等于fetchStart。

· connectStart和connectEnd分别代表TCP建立连接和连接成功的时间节点。如果浏览器没有进行TCP连接（比如使用持久化连接webscoket），则两者都等于domainLookupEnd。

· secureConnectionStart：可选。如果页面使用HTTPS，它的值是安全连接握手之前的时刻。如果该属性不可用，则返回undefined。如果该属性可用，但没有使用HTTPS，则返回。

· requestStart代表浏览器发起请求的时间节点，请求的方式可以是请求服务器、缓存、本地资源等。

· responseStart和responseEnd分别代表浏览器收到从服务器端（或缓存、本地资源）响应回的第一个字节和最后一个字节数据的时刻。

· domLoading代表浏览器开始解析html文档的时间节点。IE浏览器下的document有readyState属性，domLoading的值就等于readyState改变为loading的时间节点。

· domInteractive代表浏览器解析html文档的状态为interactive时的时间节点。domInteractive并非DOMReady，它早于DOMReady触发，代表html文档解析完毕（即dom tree创建完成）但是内嵌资源（比如外链css、js等）还未加载的时间点。

· domContentLoadedEventStart：代表DOMContentLoaded事件触发的时间节点：

页面文档完全加载并解析完毕之后,会触发DOMContentLoaded事件，HTML文档不会等待样式文件,图片文件,子框架页面的加载(load事件可以用来检测HTML页面是否完全加载完毕(fully-loaded))。

· domContentLoadedEventEnd：代表DOMContentLoaded事件完成的时间节点，此刻用户可以对页面进行操作，也就是jQuery中的domready时间。

· domComplete：html文档完全解析完毕的时间节点。

· loadEventStart和loadEventEnd分别代表onload事件触发和结束的时间节点。

可以使用Navigation.timing统计到的时间数据来计算一些页面性能指标，比如DNS查询耗时、白屏时间、domready等等。如下：

· DNS查询耗时= domainLookupEnd - domainLookupStart

· TCP链接耗时= connectEnd - connectStart

· request请求耗时= responseEnd - responseStart

· 解析dom树耗时= domComplete - domInteractive

· 白屏时间 = domloadng - fetchStart

· domready时间= domContentLoadedEventEnd - fetchStart

· onload时间= loadEventEnd - fetchStart

 

（2）Resource Timing API

可监测静态资源加载速度，详细的内容请参考W3C Resource timing。

 

如：performance.getEntries方法，它可以获取页面中每个静态资源的请求：

 

可以看到performance.getEntries返回一个数组，数组的每个元素代表对应的静态资源的信息，比如上图展示的第一个元素对应的资源类型initiatorType是图片img，请求花费的时间就是duration的值。

需要注意的是，如果使用 CDN 的话，需要让 CDN 服务商加上 Timing-Allow-Origin 的响应头，才能拿到静态资源的数据。

参考文档

[1]《前端必读：浏览器内部工作原理》

[2]《前端性能监控与分析》

[3]《7天打造前端性能监控系统》

[4]《前端性能监控方案window.performance 调研》

[5]《Performance—前端性能监控利器》