世间所有的相遇，都是久别重逢

Performance API详解

发表于 分类于 ， 阅读次数： Disqus： Valine：
本文字数： 6.9k 阅读时长 ≈ 6 分钟

Performance 接口可以获取到当前页面中与性能相关的信息。它是 High Resolution Time API 的一部分，同时也融合了 Performance Timeline API、Navigation Timing API、 User Timing API 和 Resource Timing API。

本文主要记录Performance API的几个属性、方法，以及页面加载慢问题的排查分析。

Performance API与传统getTime方法比较

为了得到脚本运行的精确耗时，需要一个精度时间戳，传统做法是使用Date对象getTime方法，不足之处：

  1. getTime方法只能精确到毫秒级别
  2. getTime方法只能获取脚本运行过程中时间进度，无法知道一些后台事件进度，比如浏览器用了多长时间从服务器加载网页

为解决这两个问题，ES5引入高精度时间戳performance API，其精度可以到达1毫秒的千分之一。

Performance API属性

timing（PerformanceTiming）

从输入url到用户可以使用页面的全过程时间统计，会返回一个PerformanceTiming对象，单位均为毫秒

按触发顺序排列所有属性：

  • navigationStart：在同一个浏览器上下文中，前一个网页（与当前页面不一定同域）unload 的时间戳，如果无前一个网页 unload ，则与 fetchStart 值相等
  • unloadEventStart：前一个网页（与当前页面同域）unload 的时间戳，如果无前一个网页 unload 或者前一个网页与当前页面不同域，则值为 0
  • unloadEventEnd：和 unloadEventStart 相对应，返回前一个网页 unload 事件绑定的回调函数执行完毕的时间戳
  • redirectStart：第一个 HTTP 重定向发生时的时间。有跳转且是同域名内的重定向才算，否则值为0
  • redirectEnd：最后一个 HTTP 重定向完成时的时间。有跳转且是同域名内的重定向才算，否则值为 0
  • fetchStart：浏览器准备好使用 HTTP 请求抓取文档的时间，这发生在检查本地缓存之前
  • domainLookupStart：DNS 域名查询开始的时间，如果使用了本地缓存（即无 DNS 查询）或持久连接，则与 fetchStart 值相等
  • domainLookupEnd：DNS 域名查询完成的时间，如果使用了本地缓存（即无 DNS 查询）或持久连接，则与 fetchStart 值相等
  • connectStart：HTTP（TCP）开始建立连接的时间，如果是持久连接，则与 fetchStart 值相等，如果在传输层发生了错误且重新建立连接，则这里显示的是新建立的连接开始的时间
  • connectEnd：HTTP（TCP） 完成建立连接的时间（完成握手），如果是持久连接，则与 fetchStart 值相等，如果在传输层发生了错误且重新建立连接，则这里显示的是新建立的连接完成的时间。注意：这里握手结束，包括安全连接建立完成、SOCKS授权通过
  • secureConnectionStart：HTTPS 连接开始的时间，如果不是安全连接，则值为 0
  • requestStart：HTTP 请求读取真实文档开始的时间（完成建立连接），包括从本地读取缓存，连接错误重连时，这里显示的也是新建立连接的时间
  • responseStart：HTTP 开始接收响应的时间（获取到第一个字节），包括从本地读取缓存
  • responseEnd：HTTP 响应全部接收完成的时间（获取到最后一个字节），包括从本地读取缓存
  • domLoading：开始解析渲染 DOM 树的时间，此时 Document.readyState 变为 loading，并将抛出 readystatechange 相关事件
  • domInteractive：完成解析 DOM 树的时间，Document.readyState 变为 interactive，并将抛出 readystatechange 相关事件。注意：只是 DOM 树解析完成，这时候并没有开始加载网页内的资源
  • domContentLoadedEventStart：DOM 解析完成后，网页内资源加载开始的时间，文档发生DOMContentLoaded事件的时间
  • domContentLoadedEventEnd：DOM 解析完成后，网页内资源加载完成的时间（如 JS 脚本加载执行完毕），文档的DOMContentLoaded 事件的结束时间
  • domComplete：DOM树解析完成，且资源也准备就绪的时间，Document.readyState 变为 complete，并将抛出 readystatechange 相关事件
  • loadEventStart：load 事件发送给文档，也即 load 回调函数开始执行的时间，如果没有绑定 load 事件，值为 0
  • loadEventEnd：load 事件的回调函数执行完毕的时间，如果没有绑定 load 事件，值为 0

下面是一些常用加载时间的计算：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
// 计算加载时间
function getPerformanceTiming () { 
    var performance = window.performance;
  
    if (!performance) {
        // 当前浏览器不支持
        console.log('你的浏览器不支持 performance 接口');
        return;
    }
  
    var t = performance.timing;
    var times = {};
  
    //【重要】页面加载完成的时间
    //【原因】这几乎代表了用户等待页面可用的时间
    times.loadPage = t.loadEventEnd - t.navigationStart;
  
    //【重要】解析 DOM 树结构的时间
    //【原因】反省下你的 DOM 树嵌套是不是太多了！
    times.domReady = t.domComplete - t.responseEnd;
  
    //【重要】重定向的时间
    //【原因】拒绝重定向！比如，http://example.com/ 就不该写成 http://example.com
    times.redirect = t.redirectEnd - t.redirectStart;
  
    //【重要】DNS 查询时间
    //【原因】DNS 预加载做了么？页面内是不是使用了太多不同的域名导致域名查询的时间太长？
    // 可使用 HTML5 Prefetch 预查询 DNS ，见：[HTML5 prefetch](http://segmentfault.com/a/1190000000633364)           
    times.lookupDomain = t.domainLookupEnd - t.domainLookupStart;
  
    //【重要】读取页面第一个字节的时间
    //【原因】这可以理解为用户拿到你的资源占用的时间，加异地机房了么，加CDN 处理了么？加带宽了么？加 CPU 运算速度了么？
    // TTFB 即 Time To First Byte 的意思
    // 维基百科：https://en.wikipedia.org/wiki/Time_To_First_Byte
    times.ttfb = t.responseStart - t.navigationStart;

    //【重要】内容加载完成的时间
    //【原因】页面内容经过 gzip 压缩了么，静态资源 css/js 等压缩了么？
    times.request = t.responseEnd - t.requestStart;
  
    //【重要】执行 onload 回调函数的时间
    //【原因】是否太多不必要的操作都放到 onload 回调函数里执行了，考虑过延迟加载、按需加载的策略么？
    times.loadEvent = t.loadEventEnd - t.loadEventStart;
  
    // DNS 缓存时间
    times.appcache = t.domainLookupStart - t.fetchStart;
  
    // 卸载页面的时间
    times.unloadEvent = t.unloadEventEnd - t.unloadEventStart;
  
    // TCP 建立连接完成握手的时间
    times.connect = t.connectEnd - t.connectStart;
  
    return times;
}

常用计算：

  • DNS查询耗时：domainLookupEnd - domainLookupStart
  • TCP链接耗时：connectEnd - connectStart
  • request请求耗时：responseEnd - responseStart
  • 解析dom树耗时： domComplete - domInteractive
  • 白屏时间：responseStart - navigationStart
  • domready时间(用户可操作时间节点) ：domContentLoadedEventEnd - navigationStart
  • onload时间(总下载时间) ：loadEventEnd - navigationStart

旨在告诉开发者当前页面是通过什么方式导航过来的，只有两个属性：type，redirectCount

type：标志页面导航类型，如下表

枚举值 常数 描述
TYPE_NAVIGATE 0 普通进入，包括：点击链接、在地址栏中输入 URL、表单提交、或者通过除下表中 TYPE_RELOAD 和 TYPE_BACK_FORWARD 的方式初始化脚本。
TYPE_RELOAD 1 通过刷新进入，包括：浏览器的刷新按钮、快捷键刷新、location.reload()等方法。
TYPE_BACK_FORWARD 2 通过操作历史记录进入，包括：浏览器的前进后退按钮、快捷键操作、history.forward()、history.back()、history.go(num)。
TYPE_UNDEFINED 255 其他非以上类型的方式进入。

redirectCount：表示到达最终页面前，重定向的次数，但是这个接口有同源策略限制，即仅能检测同源的重定向。注意：所有前端模拟的重定向都无法统计到，因为不属于HTTP重定向。

memory

描述内存多少，是在Chrome中添加的一个非标准属性。单位字节

  • jsHeapSizeLimit：内存大小限制
  • totalJSHeapSize：可使用的内存
  • usedJSHeapSize：JS对象（包括V8引擎内部对象）占用的内存，不能大于totalJSHeapSize，如果大于，有可能出现了内存泄漏

Performance API方法

getEntries()

这个函数返回的将是一个数组，包含了页面中所有的 HTTP 请求。注意 HTTP 请求有可能命中本地缓存，所以请求响应的间隔将非常短，可以看到，与 performance.timing对比，没有与 DOM 相关的属性

获取所有资源请求的时间数据，这个函数返回一个按startTime排序的对象数组，数组成员除了会自动根据所请求资源的变化而改变以外，还可以用mark()、measure()方法自定义添加，该对象的属性中除了包含资源加载时间还有以下五个属性。

  • name：资源名称，是资源的绝对路径或调用mark方法自定义的名称
  • startTime：开始时间
  • duration：加载时间
  • entryType：资源类型，entryType类型不同数组中的对象结构也不同
  • initiatorType：谁发起的请求

entryType的值：

资源类型 对象 描述
mark PerformanceMark 通过mark()方法添加到数组中的对象
measure PerformanceMeasure 通过measure()方法添加到数组中的对象
resource PerformanceResourceTiming 所有资源加载时间，用处最多
navigation PerformanceNavigationTiming 现除chrome和Opera外均不支持，导航相关信息
frame PerformanceFrameTiming 现浏览器均未支持
server PerformanceServerTiming 未查到相关资料

initiatorType的值：

对象 发起请求者 描述
a Element link/script/img/iframe等 通过标签形式加载的资源，值是该节点名的小写形式
a CSS resourc css 通过css样式加载的资源，比如background的url方式加载资源
a XMLHttpRequest object xmlhttprequest 通过xhr加载的资源
a PerformanceNavigationTiming object navigation 当对象是PerformanceNavigationTiming时返回

这里我们主要关注resource资源返回的对象：

1
2
3
4
5
6
7
8
9
// 可以用来做一个精准的进度条
PerformanceResourceTiming:{ 
    entryType: "resource",
    name: 资源的绝对路径，即URL,
    startTime: 即将抓取资源的时间,
    duration: responseEnd - startTime,
    initiatorType: 略,
    // 其他属性请参考performance.timing
}

我们可以像 getPerformanceTiming 获取网页的时间一样，获取某个资源的时间：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
// 计算加载时间
function getEntryTiming (entry) { 
    var t = entry;
    var times = {};
  
    // 重定向的时间
    times.redirect = t.redirectEnd - t.redirectStart;
  
    // DNS 查询时间
    times.lookupDomain = t.domainLookupEnd - t.domainLookupStart;
  
    // 内容加载完成的时间
    times.request = t.responseEnd - t.requestStart;
  
    // TCP 建立连接完成握手的时间
    times.connect = t.connectEnd - t.connectStart;
  
    // 挂载 entry 返回
    times.name = entry.name;
    times.entryType = entry.entryType;
    times.initiatorType = entry.initiatorType;
    times.duration = entry.duration;
  
    return times;
}
  
// test
// var entries = window.performance.getEntries();
// entries.forEach(function (entry) {
//     var times = getEntryTiming(entry);
//     console.log(times);
// });

getEntriesByName(name,type[optional])

根据想要筛选出的资源名，返回值仍是一个数组。

getEntriesByType(type)

根据资源类型来筛选，返回值仍是一个数组。

页面加载慢问题排查分析

请求stalled耗时长

因为浏览器每个浏览器同一时间访问相同主机域名是是有数量限制的，chrome的最大限制是6，当后续在发请求会进行延迟等待

网站加载 Waiting (TTFB) 时间过长

什么是 Waiting (TTFB) 时间

TTFB 是 Time to First Byte 的缩写，指的是浏览器开始收到服务器响应数据的时间（后台处理时间+重定向时间），是反映服务端响应速度的重要指标。就像你问朋友了一个问题，你的朋友思考了一会儿才给你答案，你朋友思考的时间就相当于TTFB。你朋友思考的时间越短，就说明你朋友越聪明或者对你的问题越熟悉。对服务器来说，TTFB时间越短，就说明服务器响应越快。

TTFB时间多长算长？

TTFB 时间如果超过了 500 ms，用户在打开网页的时候就会感觉到明显的等待。所以可以把 500 ms 以上认为是 TTFB 时间过长。

TTFB过长的原因

  • 接口的性能比较低
  • 服务器到用户之间的网络不好
  • 页面在用户的浏览器中保存了过多的 Cookie，每次请求，这些 Cookie 都要发送到服务器，服务器都要处理这些 Cookie

Waiting (TTFB) 时间过长的解决办法

  • 接口性能原因：接口性能优化，数据库查询性能优化，使用缓存
  • 网络原因：CDN
  • Cookie原因：修改应用程序，删除一些不必要的 Cookie，或者精简 Cookie 内容，缩短 Cookie 的有效期等

参考

推荐文章

----------- 本文结束啦感谢您阅读 -----------

赞赏一杯咖啡

欢迎关注我的其它发布渠道

disqus valine