html5 performance 的应用尝试.
var namespace = {};
void function (window, document, ns, undefined){
ns = window[ns];
if(!window.performance || ns.Performance){
//performance api , (Date : 2011-11), ie9+(包括兼容模式), chrome11+, Firefox7+ . (Safari,Opera. 没有实现)
return;
}
var mixin = function (oTarget ,oSource) {
var s;
for (s in oSource){
if(oSource.hasOwnProperty(s)){
oTarget[s] = oSource[s];
}
}
return oTarget;
},
performance = window.performance,
timing = performance.timing,
navigation = performance.navigation,
create = function (properties) {
var obj;
if(Object.create){
return Object.create(null, properties);
}
obj = {};
for (var s in properties){
/*
ie9+ 兼容模式. performance 可用，但ES5 相关特性不可用.
但是getter 的设计,本来是为了解决.获取时间不正确的状况处理的.
比如 responseTime 的设计. 为了解决这个问题.引入了update接口.
*/
if(properties.hasOwnProperty(s)){
if(typeof properties[s].get == 'function'){
//如果属性是一个函数,那么就应该是需要延迟获取的属性.则调用相关get方法获取当前值.
obj[s] = properties[s].get();
}else{
obj[s] = properties[s].value;
}
}
}
return obj;
},
properties = {
isDirectClientCache : {//是否直接走的客户端缓存.
value : function () {
if(navigation.type === 1){//刷新的访问,自然不可能直接走cache.
return false;
}
if(timing.requestStart === 0){//Firefox7,当直接走缓存时request,connect相关时间节点都为0
return true;
}
if(timing.connectStart === timing.connectEnd){//Freifox8+,Chrome11+,IE9+
//应注意的是,有时候304时, 如果资源问本地文件，chrome会因为connect连接建立过快，而导致 此处为true. 但基本线上应不会出现此类问题.
//另一个解决思路是对比responseStart和responseEnd.但这个受干扰影响更多.更不靠谱.
return true;
}
return false;
}()
},
navigationType : {
value : navigation.type
/*
0 nomal get or link .
1 reload.
2 back forward.
3 reserved . (oters method.)
但应注意的是,Firefox8+,开始又恢复了Firefox3.5-的老问题，即返回（后退）的方式访问页面，onload不会被触发.
所以如果搜集信息上报,是在onload回调中,就要警惕,Firefox8+浏览器，会导致上报脚本，没有被执行的问题.
Opera,Safari 也存在同样的问题,将来这两款浏览器支持performance时也应注意.
另外一个问题就是,domContentLoaded事件存在onload同样的问题.只有IE和Chrome,没有这个问题.
最靠谱的做法是注册到onpageshow上(如果浏览器支持的话). 否则.除非我们牺牲精准度.来直接执行脚本...
辅onpageshow 事件支持情况:
onpageshow的支持列表:
Firefox 1.5 +
Safari5+
Chrome4+
Opera12,IE10 PP2,至今仍未支持 .
*/
},
redirectCount : {//只能统计到同源的重定向次数.
value : navigation.redirectCount
},
redirectTime : {//重定向消耗的时间.
value : timing.redirectEnd - timing.redirectStart
},
/* fetchTime,我们 拿到，没什么价值，也没有优化的可能性存在.
fetchTime : {
value : Math.max(timing.domainLookupStart - timing.fetchStart, 0)
//Firefox的domainLookupStart，如果因没有发生dns look up ,则该值不是fetchStart,而是navigationStart的值.并没有遵守标准.
},
*/
domainLookupTime : {
value : timing.domainLookupEnd - timing.domainLookupStart
},
connectTime : {//注意,这个不是连接保持的时间,而是与服务器端建立连接所花费的时间.
value : timing.connectEnd - timing.connectStart
},
requestTime : {//因为木有准确的获取RequestEnd的有效办法.所以这个值实际上是我们接收到服务器响应数据的那个时间 减去发出HTTP请求，所花费的时间.
//注意,Firefox 7,在走cache时.requestStart,会为0.Firefox8以修复.当无法正确获取时,我们应该返回 -1.
value : timing.responseStart - (timing.requestStart || timing.responseStart + 1)
}
},
deferrProperites = {
//延时的属性
responseTime : {
/*
.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的情况下.）.会根据每次接收到的数据块的时间,去更新.responseEnd的时间.
Chrome17-,Firefox7,则在分段数据的接受过程中，不会更新.responseEnd的时间,其值,始终为0.
基于不确定性,所以该值被获取的时如果过早，就返回 -1, 否则返回正确的值.
DomContentLoaded., 即语义上的DOM Parse 也早已结束了.而且其他资源也都加在完毕了. 而更早的 domInteractive .IE系列存在bug:
IE9 - IE10 PP2(IE10,走cache情况除外). 在分段输出文档的情况下，该值并不是全部文档解析完成后的时间,而是第一个数据块被解析完成的时间.
实现差异:(由于草案中，并未提及,文档解析并未结束时,其默认值的应该是多少.导致浏览器实现有差异.)
按我个人理解，并未解析结束，应该为0. 但是IE似乎对这个东西理解不太一样. 其他浏览器会是0.
但是. IE9-IE10 PP2,则会比较有趣.即使是分段输出,我取到的值.也和onload以后去到的,domInteractive的值是一致的.
导致这一神奇现象的原因是,正式IE系的bug所导. 该时间是错误的引用了,DOM解析完成第一个数据块的时间.而不是整个文档的.
但是纠结起来就要挖掘更深层次的原因了. 因为草案只说该值体现的是,用户代理把"current document readiness" 设置为 "interactive"的时间.
如果IE系处理分段输出的html文档，向来都是这样做的。那么该值与其他浏览器的差异。也是可以理解的.
基于，以上综合原因，所以决定借助domContentLoadedEventStart 检测来确定responseTime是否可信. 如不可信，则返回-1.
*/
get : function () {//此值IE9仅共参考.并不值信任.IE10则可信任.
var val = timing.responseEnd - timing.responseStart;
if(timing.domContentLoadedEventStart){
if(val < 0 ) {//修正chrome16- 走cache时的bug.
val = 0;
}
}else {
val = -1;
}
return val;
}
},
domParsingTime : {//IE系不可信任.职能期待IE系将来的实现了.
get : function () {
/*
注意IE9 - IE10 PP2,bug. IE下，这个计算出来的值，仅共参考.完全不靠谱.
iE9 - IE10 PP2 , 当文档是chunked方式输出的时候.总是要等最后一个chunked被浏览器接收后,
domLoading才会有有效值. 也就是说,IE中目前的状况是.domLoading.无论如何，都要晚于responseEnd.
其他浏览器则无此问题. 但是这个问题导致我们计算IE下DOM Parsing等后续的一系列时间不准确.
即 domInteractive - domLoading 甚至会经常得到0.
*/
return timing.domContentLoadedEventStart ? timing.domInteractive - timing.domLoading : -1;
}
},
resourcesLoadedTime : {//IE系列不可信任,原因当然是分段输出问题.domLoading不准确,导致后续计算都不准确的问题.所以仅供参考.
/*
此时间指的是.页面所有onload计算范围内的资源加载结束后到文档开始进行dom parse的时间段.
*/
get : function () {
return timing.loadEventStart ? timing.loadEventStart - timing.domLoading : -1;
}
},
firstPaintTime : {//从导航到页面首次渲染所消耗的时间.(该属性并非标准的属性.而是微软私有的.目前IE9+支持)
get : function () {//如果都不支持该属性，或，读取该属性时，页面还没有渲染,则返回 -1;
//这段代码是一个愿望，希望将来,firstPaint 将进入草案，并被浏览器实现.哪怕他们依赖前缀.
var t = timing.firstPaint ||
timing.msFirstPaint ||
timing.mozFirstPaint ||
timing.webkitFirstPaint ||
timing.oFirstPaint;
return t ? t - timing.fetchStart : -1;
}
},
domContentLoadedTime : {//从导航 到 页面domReady所消耗的时间.
get : function () {
return timing.domContentLoadedEventStart ? timing.domContentLoadedEventStart - timing.fetchStart : -1;
}
},
windowLoadedTime :{//获取当前文档fetchStart 到 window.onload,所花费的总时间.
get : function () {
return timing.loadEventStart ? timing.loadEventStart - timing.fetchStart : -1;
}
}
},
pfm = create(mixin(properties, deferrProperites));
ns.Performance = pfm;
if(Object.defineProperty){//单体对象的方法，没有必要挂在到prototype上. so ..
Object.defineProperty(pfm, 'update', {value : function () {return this;}});
}else{ //for IE9+,兼容模式. 需要每次依赖update方法，每次都去手动更新那些不靠谱的东西.
pfm.update = function () {
for (var s in deferrProperites){
if(deferrProperites.hasOwnProperty(s)){
pfm[s] = deferrProperites[s].get();
}
}
}
}
}(window, document, 'namespace');
window.onload = function () {
setTimeout(function () {
var pfm = namespace.Performance;
pfm.update();
alert([
'isDirectClientCache : ' + pfm.isDirectClientCache,
'navigationType : ' + pfm.navigationType,
'redirectCount : ' + pfm.redirectCount,
'redirectTime : ' + pfm.redirectTime,
'domainLookupTime : ' + pfm.domainLookupTime,
'connectTime : ' + pfm.connectTime,
'requestTime : ' + pfm.requestTime,
'responseTime : ' + pfm.responseTime,
'domParsingTime : ' + pfm.domParsingTime,
'resourcesLoadedTime : ' + pfm.resourcesLoadedTime,
'firstPaintTime : ' + pfm.firstPaintTime,
'domContentLoadedTime : ' + pfm.domContentLoadedTime,
'windowLoadedTime : ' + pfm.windowLoadedTime
].join('\n'));
}, 300);
}
一切都在注释里了. 有兴趣可以看看.
要补充的是，这段代码的测试环境: Chrome11+,Firefox7+,IE9+, 别的浏览器就没办法了. 另外，代码适当使用了ES5的api . 如果不是为了这一点,那么其实这套api应该设计成另外的样子. 而不是属性器. 因为我终于是被IE9的兼容模式,给搅和了. 为了兼容.不得不设计出update 接口出来...
