HTML5的学习--performance

HTML5提供的performance接口精确的告诉咱们当访问一个网站页面时当前网页每一个处理阶段的精确时间(timestamp)，以方便咱们进行前端分析。

它是浏览器的直接实现，比在网页中用js设置Date.time或者cookie来分析网页时间上要精确不少。

支持浏览器: IE9+,Chrome11+,Firefox7+.

如下是w3c提供的performance.timing各阶段api图

成员:

.navigation (一个叫作performanceNavigation的对象.)

.timing (这是一个被称做performanceTiming的包含了不少成员的对象) 

 

PS:

1. performance,仅能对当前的html文档作检测，全部的对象都和当前文档有关。若是咱们想检测某个图片资源的网络情况,则不行。 好比咱们想监控，用户访问咱们服务的情况，就只能建立一个iframe，url为咱们服务某个地址(除非用户访问的当前页，就是咱们要监控的对象)。而后才能够监控此次一次请求的网络状态等等。因此建议若是能够考虑使用performance作监控，则须要有抽样、时间点等监控机制。不然给服务器带来额外压力，得不偿失。若是要监控其余资源，须要使用 ResourceTiming。 

 

performanceNavigation(performance.navigation)对象的成员

performanceNavigation.type 

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

0 : TYPE_NAVIGATE  (用户经过常规导航方式访问页面,好比点一个连接，或者通常的get方式.)

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

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

ps:草案中其实还有 3 : TYPE_RESERVED (保留,其余非前三种方式访问.)

 

performanceNavigation.redirectCount

一个只读属性，返回当前页面是几回重定向才过来的。可是这个接口有同源策略限制，即仅能检测同源的重定向。

bugs:

　　1. IE9，当一个同源的页面a链接到地址b(是否于a,c同源都如此)，后被重定向到同源页面c时，navigation.redirectCount竟然会是1。而不是0，此bug已被IE10 PP2修复。

 

performanceTiming(performance.timing)对象的成员:

.navigationStart 

浏览器完成卸载前一个文档的时间(也就是准备加载新页面的那个起始时间)。若是没有前一个文档，那么就返回 timing.fetchStart的值。

彷佛只有Chrome 很是严格遵照了此草案。 即不把刷新页面，以及一个标签页输入地址到指定页面，视为发生文档的卸载。

bugs:

     1. IE9,当发生重定向时，.navigationStart 会是0。IE10 PP2 已修复此问题.

     2. IE9-IE10 PP2，的一个问题是刷新当前页面，或在某个标签页输入地址为非相同页面时，会被视为存在前一个文档，也就是说,其navigationStart会早于fetchStart。(除非在当前页再次输入地址按回车。再次进入该页面，则被视为无前一个文档被卸载)。而实际上这时候navigationStart，是unloadEventEnd的时间。

     3. Firefox7-Firefox10，一个新标签页也会被视为一个有效的文档。因此这时候,会有值，且不是fetchStart的值。

.unloadEventStart

若是前一个文档，和当前文档同源,返回前一个文档发生unload事件前的时间.若是没有前一个文档，或不一样源,则返回0.

bugs:

     1. IE9-IE10 pp2,Chrome17-,在前一个文档与当前文档中间发生重定向时, 且先后两个文档同源时, unloadEventStart,也会返回0

.unloadEventEnd

若是前一个文档和当前文档同源.返回前一个文档发生unload事件的时间. 若是没有前一个文档，或不一样源，则返回0。

若是,发生了HTTP重定向，或者相似的事情。而且,从导航开始中间的每次重定向，并不都和当前文档同域的话，则返回0。

bugs:

     1. IE9-IE10 pp2,Chrome17-，在前一个文档与当前文档中间发生重定向时，且先后两个文档同源时，unloadEventEnd也会返回0。

.redirectStart

若是,发生了HTTP重定向，或者相似的事情。而且，从导航开始，中间的每次重定向，都和当前文档同域的话，就返回开始重定向的，timing.fetchStart的值。其余状况，则返回0。

bugs:

     1. IE9-IE10 pp2,在页面a，连接到地址b，并重定向到与b同源的页面c时。redirectStart,将为0.即同源策略，竟然会考虑导航页。

.redirectEnd

若是,发生了HTTP重定向,或者相似的事情.而且,从导航开始,中间的每次重定向，都和当前文档同域的话,就返回最后一次重定向，接收到最后一个字节数据后的那个时间.其余状况则返回0.

bugs:

     1. IE9-IE10 pp2,在页面a,连接到地址b,并重定向到与b同源的页面c时. redirectSEnd,将为0.即同源策略，竟然会考虑导航页.

.fetchStart

若是一个新的资源(这里是指当前文档)获取被发起,或相似的事情发生,则 fetchStart必须返回用户代理开始检查其相关缓存的那个时间,其余状况则返回开始获取该资源的时间.

.domainLookupStart 

返回用户代理对当前文档所属域进行DNS查询开始的时间. 若是此请求没有DNS查询过程,如长链接，资源cache,甚至是本地资源等. 那么就返回 fetchStart的值.

bugs:

     1. Firefox7-Firefox10,的实现有错误. 由于其值,并无遵照标准所描述的对应时间节点.而是默认以navigationStart做为时间起点,并以中间的重定向时间作累加.而获得domainLookupStart的时间.即便这个重定向是非同源的重定向.所消耗的时间都会被计算进去. 那么，这也就解释了，为何当没有重定向发生时, domainLookupStart - fetchStart, 咱们每每会获得一个负值的缘由,由于navigationStart,是要早于 fetchStart的.

.domainLookupEnd

返回用户代理对结束对当前文档所属域进行DNS查询的时间.若是此请求没有DNS查询过程,如长链接，资源cache,甚至是本地资源等. 那么就返回 fetchStart的值.

bugs:

     1.参考domainLookupStart的bug. End具有相同的问题.

.connectStart

返回用户代理向服务器服务器请求文档，开始创建链接的那个时间,若是此链接是一个长链接,又或者直接从缓存中获取资源（即没有与服务器创建链接）.则返回domainLookupEnd的值.

bugs:

     1. Firefox7 当资源走cache,即并未建立链接时. connentStart 的值为0.

     2. Firefox8-Firefox10,当并未建立链接时,connetStart的值是fetchStart的值，而不是domainLookEnd的值. 但这里涉及到一个惯性问题，由于domainLookupEnd的累积时间就已经背离了标准了，因此即便connectStart遵照标准.也是一个有问题的值.

.connectEnd

返回用户代理向服务器服务器请求文档，创建链接成功后(注意，不是断开链接的时间.)的那个时间.若是此链接是一个长链接，又或直接从缓存中获取资源 （即没有与服务器创建链接）,则返回domainLookupEnd的值.

bugs:

     参考connectStart的问题.connectEnd具有一样的问题.

若是链接创建失败,而用户代理进行重连,则connectStart和connectEnd则应该是此次重连的相关的值.其中connectEnd必须包括创建链接的时间以及,SSH握手协议和SOCKS认证等时间.

.secureConnectionStart

可选特性.用户代理若是没有对应的东东,就要把这个设置为undefined.若是有这个东东,而且是HTTPS协议,那么就要返回开始SSL握手的那个时间. 若是不是HTTPS, 那么就返回0.

补充:Firefox7-10,IE9-IE10 PP2,都木有实现这个api.因此始终是undefined.

.requestStart

返回从服务器、缓存、本地资源等,开始请求文档的时间. 

若是请求中途,链接断开了,而且用户代理进行了重连，并从新请求了资源,那么requestStart就必须为这个新请求所对应的时间.

     performance.timing 并不包含一个 单表请求结束的"requestEnd"接口. 缘由有两点:

          1. 用户代理所能肯定的请求的结束,并不能表明正确的网络栓书中的结束时间. 因此设计这个属性并没什么用处.

          2. 一些用户代理，若是要封装一个表明HTTP层面的，请求结束时间的接口,成本会很是高昂.

bugs: 

     1. Firefox7,直接走本地缓存时,.requestStart的值将为0. (Firefox8已修复此问题)

.responseStart

返回用户代理从服务器、缓存、本地资源中，接收到第一个字节数据的时间.

.responseEnd

返回用户代理接收到最后一个字符的时间，和当前链接被关闭的时间中，更早的那个. 一样,文档可能来自服务器、缓存、或本地资源.

补充: 此值的读取应该是在咱们能够确保真的是Response结束之后. 好比window.onload.  由于考虑到chunked输出的状况. 那么咱们脚本执行，并获取该值时，响应尚未结束. 这就会致使获取时间不许确.

bugs : 

     1. IE10 PP2, 以及Chrome17- ，走本地缓存时.在文档中间的脚本执行时去读取此值, 将为0. IE9原本没有问题,结果IE10 PP2,反倒有了问题.

     2. Chrome16-,(Chrome17,已修复此问题.)在地址栏输入相同地址,走本地缓存时. responseEnd的时间，竟然早于responseStart的时间. （不得不认可，这简直就是奇葩啊!）

     3. Chrome17-,从页面a,到地址b,再重定向到地址c, 此时若是地址c是走缓存.则. ResponseEnd的时间，会遭遇ResponseStart的时间.(好吧,咱们把但愿寄予Chrome18好了.)

实现差别:(因为草案中，并未说起,当文档被分段输出后.在中间文档数据，接受过程当中,responseEnd应如何处理,致使浏览器实现存在差别.)

     IE9 - IE10 PP2 , Firefox8-Firefox10,在不走存在Response阶段（非走cache的状况下.）.以接收第一个chunked包结束的时间做为.responseEnd的时间.(这将致使后续的一系列问题.)

     Chrome17-,Firefox7,则在分段数据的接受过程当中，不会更新.responseEnd的时间,其值,始终为0.

.domLoading 

返回用户代理把其文档的 "current document readiness" 设置为 "loading"的时候.

(current document readiness 其实就是document.readyState API对应的状态.)

参考:http://dev.w3.org/html5/spec/dom.html#current-document-readiness

bugs : 

     1. IE9. 在分段输出文档的状况下，该值老是要晚于最终responseEnd的值. 基于responseEnd的IE实现的bug.这也合情合理.

实现差别:

     iE9 - IE10 PP2 , 当文档是chunked方式输出的时候.老是要等最后一个chunked被浏览器接收后,domLoading才会有有效值.  也就是说,IE中目前的情况是.domLoading.不管如何，都要晚于responseEnd.其余浏览器则无此问题.  可是这个问题致使咱们计算IE下DOM Parse不许确. 即 domInteractive - domLoading 甚至会常常获得0. 

.domInteractive

返回用户代理把其文档的 "current document readiness" 设置为 "interactive"的时候.

从标准来讲,domReady的状态为"interactive"时,意味着,文档解析结束了. 由于标准中描述, DOM树建立结束后第一件事，就是把 "current document readiness" 设置为"interactive"

参考:http://dev.w3.org/html5/spec/the-end.html#the-end 中第一步.

bugs : 

     1. IE9,IE10 PP2 . 在分段输出文档的状况下，该值并非所有文档解析完成后的时间,而是第一个数据块被解析完成的时间,基于responseEnd的IE实现的bug.通过向后推定这也合情合理.

实现差别:(因为草案中，并未说起,文档解析并未结束时,其默认值的应该是多少.致使浏览器实现有差别.)

    按我我的理解，并未解析结束，应该为0. 可是IE彷佛对这个东西理解不太同样. 其余浏览器会是0. 可是. IE9-IE10 PP2,则会比较有趣.即便是分段输出,我取到的值.也和onload之后去到的,domInteractive的值是一致的.  致使这一神奇现象的缘由是,正式IE系的bug所导. 该时间是错误的引用了,DOM解析完成第一个数据块的时间.而不是整个文档的. 可是纠结起来就要挖掘更深层次的缘由了. 由于草案只说该值体现的是,用户代理把"current document readiness" 设置为 "interactive"的时间.若是IE系处理分段输出的html文档，向来都是这样作的。那么该值与其余浏览器的差别。也是能够理解的. 

.domContentLoadedEventStart

返回文档发生 DOMContentLoaded事件的时间.

参考:http://dev.w3.org/html5/spec/the-end.html#the-end  中第4步.

DOMContentLoad和 DOMInteractive 之间差了两个步骤. 其中之一是, 全部open elements出栈 ，而后去看看 待运行的script list中是否有须要运行的脚本,若是有则执行，一直到这个列表为空了.再触发DOMContentLoad.  须要主的是这个待运行脚本列表.有些可能在不一样浏览器中，被加入进去的行为可能不一样. 好比 document.write写入文档流的脚本，以及script deferr 的脚本.. 因此咱们应该知道deferr的脚本也是要他推迟domContentLoaded的，也就是咱们最经常使用的所谓domReady.(至少html5的规范是如此.)

.domContentLoadedEventEnd

文档的DOMContentLoaded 事件的结束时间.

补充:所谓事件结束的时间，是指，若是DOMContentLoaded事件被开发者注册了回调事件.那么这个时间的End时间减去Start的时间.就会是这个回调执行的大概事件. 固然居于部分浏览器实现可能会有2-3ms的偏差. 可是这个时间，基本能够忽略不计. 相似的状况还有后面的.loadEventStart,End. 即 window.onload 全部回调所消耗的时间.

.domComplete

返回用户代理把其文档的 "current document readiness" 设置为 "complete"的时候.

PS:若是 current document readiness 的某个状态被屡次触发，那么对应的  domLoading, domInteractive, domContentLoadedEventStart, domContentLoadedEventEnd and domComplete这些对应的API返回的时间,就应该是这个状态第一次触发的时间.

.loadEventStart

文档触发load事件的时间. 若是load事件没有触发,那么该接口就返回0.

.loadEventEnd

文档触发load事件结束后的时间. 若是load事件没有触发,那么该接口就返回0.

external : 另外,我很期待微软的私有实现,msFirstPaint 的属性。可以获得标准的采纳...这样对于监控浏览器首次渲染花费的时间.有过重大的意义了。 

Chrome 也有了一些私有支持:

chrome.loadTimes()

 

下面是获取基本的运行时间信息的代码

var timing = performance.timing;
var readyStart = timing.fetchStart - timing.navigationStart;
var redirectTime = timing.redirectEnd  - timing.redirectStart;
var appcacheTime = timing.domainLookupStart  - timing.fetchStart;
var unloadEventTime = timing.unloadEventEnd - timing.unloadEventStart;
var lookupDomainTime = timing.domainLookupEnd - timing.domainLookupStart;
var connectTime = timing.connectEnd - timing.connectStart;
var requestTime = timing.responseEnd - timing.requestStart;
var initDomTreeTime = timing.domInteractive - timing.responseEnd;
var domReadyTime = timing.domComplete - timing.domInteractive; //过早获取时,domComplete有时会是0
var loadEventTime = timing.loadEventEnd - timing.loadEventStart;
var loadTime = timing.loadEventEnd - timing.navigationStart;//过早获取时,loadEventEnd有时会是0


console.log('准备新页面时间耗时: ' + readyStart);
console.log('redirect 重定向耗时: ' + redirectTime);
console.log('Appcache 耗时: ' + appcacheTime);
console.log('unload 前文档耗时: ' + unloadEventTime);
console.log('DNS 查询耗时: ' + lookupDomainTime);
console.log('TCP链接耗时: ' + connectTime);
console.log('request请求耗时: ' + requestTime);
console.log('请求完毕至DOM加载: ' + initDomTreeTime);
console.log('解释dom树耗时: ' + domReadyTime);
console.log('load事件耗时: ' + loadEventTime);
console.log('从开始至load总耗时: ' + loadTime);

 

摘自：

http://www.cnblogs.com/_franky/archive/2011/11/07/2238980.html

http://www.th7.cn/web/html-css/201311/14802.shtml