Performance 接口可以获取到当前页面中与性能相关的信息。它是 High Resolution Time API 的一部分,同时也融合了 Performance Timeline API、Navigation Timing API、 User Timing API 和 Resource Timing API。
本文主要记录Performance API的几个属性、方法,以及页面加载慢问题的排查分析。
Performance API与传统getTime方法比较
为了得到脚本运行的精确耗时,需要一个精度时间戳,传统做法是使用Date对象getTime方法,不足之处:
- getTime方法只能精确到毫秒级别
- 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 | // 计算加载时间 |
常用计算:
- DNS查询耗时:domainLookupEnd - domainLookupStart
- TCP链接耗时:connectEnd - connectStart
- request请求耗时:responseEnd - responseStart
- 解析dom树耗时: domComplete - domInteractive
- 白屏时间:responseStart - navigationStart
- domready时间(用户可操作时间节点) :domContentLoadedEventEnd - navigationStart
- onload时间(总下载时间) :loadEventEnd - navigationStart
navigation
旨在告诉开发者当前页面是通过什么方式导航过来的,只有两个属性: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 | // 可以用来做一个精准的进度条 |
我们可以像 getPerformanceTiming 获取网页的时间一样,获取某个资源的时间:
1 | // 计算加载时间 |
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 的有效期等