使用HTML5监测网站性能

在这个信息爆炸的互联网时代，愈来愈多的人缺乏了等待的耐心，网站性能对于一个网站来讲愈来愈重要。如下为监控到的网站打开时间对跳出率的影响：

• 当网站打开时间在0-1秒时，跳出率为12%
• 当网站打开时间在1-2秒时，跳出率为26%
• 当网站打开时间在2-3秒时，跳出率为30%

从上面的数据很明显的能够看到网站的打开速度对用户体验或者网站信任度的影响会产生多大的影响。

1、如何监控网站的性能

一、工具类

这部分主要介绍的是网站性能的检测工具，工具类的监控主要优势是调试方便，缺点就是不能准确的或者用户的真实访问数据。具体的工具备：

• Google Page Speed  https://developers.google.com/speed/pagespeed/
• Google Speed Tracer  https://developers.google.com/web-toolkit/speedtracer/?hl=zh-CN
• Yahoo Yslow http://yslow.org/
• Fiddler http://fiddler2.com/ （软件介绍）
• HttpWatch http://www.httpwatch.com/
• HTTP  Analyzer http://www.ieinspector.com/

上面的工具备的免费，有点收费，可是整体的功能差很少。其中Google Speed Tracer使用起来可能会比较麻烦些，有机会在详细介绍这个工具的使用方法。

二、探测类

普通测试类的网站有：

• 360网速测试 http://webscan.360.cn/tools/http
• 17测 http://www.17ce.com/
• 卡卡网 http://www.webkaka.com/
• Webluker http://www.webluker.com/webtools/net

详细测试类的网站有：

阿里测 http://www.alibench.com/ （来自于阿里巴巴，抄袭对象为 http://www.webpagetest.org/）

三、监控类

• 监控宝 http://www.jiankongbao.com/
• 基调网络 http://www.networkbench.com/

四、服务器监控

• Nagios http://www.nagios.org/
• Cacti http://www.cacti.net/

2、监控系统的现状

目前第三方监控作的较好的主要为基调网络和监控宝，其中基调网络监控的数据更加详细完整，属于高富帅产品，而监控宝相对的更加平民化些，如下是针对这两个服务的分析。

优点

1. 无需改动现有程序代码。第三方监控因为采用主动访问并采集的机制，只须要在用户管理界面配置相关页面的URL，就能够模拟用户访问的过程，于是彻底不须要开发人员介入。
2. 能采集到丰富的数据。由于模拟访问使用的浏览器由供应商部署，因此能够在客户端加入自定义插件或集成其余性能工具，能经过编程实现各种性能数据的采集。

劣势

1. 成本比较大，以基调为例，若是要作到天天，每半小时监控一次的话，假设须要监控的终点页面为20个，全国要监控50个节点，每一个节点3个线路，每一个线路两台电脑的话，大概费用是天天1500元。而监控宝相对于基调网络监控的数据比较单一，成本相对要低些，每一年要作到基本全面监控须要花4000元。
2. 监控点有限，不能覆盖总体用户群。监控点能够增长，但老是没法覆盖全部的网络环境，好比用户开着迅雷下下载内容等，所以数据只能用于参考，并不能表明真实用户感觉。
3. 监控有时间间隔，都是按事先设定好的频率进行监控，在间隔中间点如发生问题，没法获知，且频率与费用成正比关系，频率越高费用越高。
4.  对于强依赖流程进入的页面难以监控。例如预订流程，须要POST大量信息，且有时效性，对于监测点来讲具备必定的挑战。

另外除了上述两种方法，前面的文章中说到了能够用GA来统计网站打开时间。具体原理为：

在页面的头部和底部分添加

• var _nStartTime = new Date().getTime();
• var _nEndTime = new Date().getTime();

二者的时间时间差即为页面的打开时间。可是此方法有不少的弊端，仅仅是统计了用户的部分耗时，其中不包括，链接时间、DNS解析时间、首包时间等。上述统计的时间，并不能真实的反应用户的打开时间。

3、性能监控须要关注哪些指标

如下为一些指标主要针对前台页面的加载。

• 页面加载时间：从DNS解析开始到返回全部文件内容所用的时间
• DNS解析时间：网站域名经过 DNS 服务器解析到IP地址的时间
• 初始化链接时间：浏览器和WEB服务器创建TCP/IP链接的消耗时间
• 首字节时间：从发起页面请求至服务器端返回第一个字节
• 下载时间：从接收服务器发回的第一字节至主页面下载完成
• 渲染时间：从页面跳转至页面Dom元素稳定。

4、HTML5提供了哪些信息

HTML5草案中提供了 window.preformance的API，可经过此API进行网站新能的监测。全部数据可以使用javascript获取window.performance.timing中的以下属性获取：

其中每一个属性的具体含义为：

对象：window.performance.

成员:

• .navigation (一个叫作performanceNavigation的对象.)
• .timing (这玩意是一个被称做performanceTiming的包含了不少成员的对象)

方法:

• .toJSON （返回一个对象，并抄写performance的可枚举成员到其中）

performanceNavigation(performance.navigation)对象的成员

performanceNavigation.type

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

• 0 : TYPE_NAVIGATE  (用户经过常规导航方式访问页面，好比点一个连接或者通常的get方式)
• 1 : TYPE_RELOAD  (用户经过刷新，包括JS调用刷新接口等方式访问页面)
• 2 : TYPE_BACK_FORWARD (用户经过后退按钮访问本页面)
• 3 : TYPE_RESERVED (保留，其余非前三种方式访问)

performanceNavigation.redirectCount

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

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

• .navigationStart 浏览器完成卸载前一个文档的时间（也就是准备加载新页面的那个起始时间）。若是没有前一个文档，那么就返回timing.fetchStart的值。彷佛只有Chrome很是严格遵照了此草案，即不把刷新页面以及一个标签页输入地址到指定页面视为发生文档的卸载。
• .unloadEventStart 若是前一个文档和当前文档同源，返回前一个文档发生unload事件前的时间。若是没有前一个文档或不一样源则返回0。
• .unloadEventEnd 若是前一个文档和当前文档同源，返回前一个文档发生unload事件的时间。若是没有前一个文档或不一样源则返回0。若是，发生了HTTP重定向或者相似的事情。而且从导航开始中间的每次重定向，并不都和当前文档同域的话则返回0。
• .redirectStart 若是发生了HTTP重定向或者相似的事情，而且从导航开始中间的每次重定向都和当前文档同域的话就返回开始重定向的timing.fetchStart的值。其余状况则返回0。
• .redirectEnd 若是发生了HTTP重定向或者相似的事情，而且从导航开始中间的每次重定向都和当前文档同域的话就返回最后一次重定向，接收到最后一个字节数据后的那个时间。其余状况则返回0。
• .fetchStart 若是一个新的资源（这里是指当前文档）获取被发起或相似的事情发生则fetchStart必须返回用户代理开始检查其相关缓存的那个时间，其余状况则返回开始获取该资源的时间。
• .domainLookupStart 返回用户代理对当前文档所属域进行DNS查询开始的时间。若是此请求没有DNS查询过程，如长链接、资源cache、甚至是本地资源等那么就返回fetchStart的值。
• .domainLookupEnd 返回用户代理对结束对当前文档所属域进行DNS查询的时间。若是此请求没有DNS查询过程，如长链接、资源cache、甚至是本地资源等. 那么就返回fetchStart的值。
• .connectStart 返回用户代理向服务器服务器请求文档开始创建链接的那个时间，若是此链接是一个长链接又或者直接从缓存中获取资源（即没有与服务器创建链接）则返回domainLookupEnd的值。
• .connectEnd 返回用户代理向服务器服务器请求文档创建链接成功后（注意，不是断开链接的时间）的那个时间。若是此链接是一个长链接又或直接从缓存中获取资源 （即没有与服务器创建链接）,则返回domainLookupEnd的值。若是链接创建失败而用户代理进行重连则connectStart和connectEnd则应该是此次重连的相关的值。其中connectEnd必须包括创建链接的时间以及SSH握手协议和SOCKS认证等时间。
• .secureConnectionStart 可选特性。用户代理若是没有对应的东东就要把这个设置为undefined，若是有这个东东而且是HTTPS协议那么就要返回开始SSL握手的那个时间。若是不是HTTPS那么就返回0。
• .requestStart 返回从服务器、缓存、本地资源等开始请求文档的时间。若是请求中途链接断开了而且用户代理进行了重连并从新请求了资源，那么requestStart就必须为这个新请求所对应的时间。
• .responseStart 返回用户代理从服务器、缓存、本地资源中接收到第一个字节数据的时间。
• .responseEnd 返回用户代理接收到最后一个字符的时间，和当前链接被关闭的时间中更早的那个。一样文档可能来自服务器、缓存、或本地资源。
• .domLoading 返回用户代理把其文档的“current document readiness”设置为“loading”的时候。（current document readiness 其实就是document.readyState API对应的状态。）
• .domInteractive 返回用户代理把其文档的“current document readiness”设置为“interactive”的时候。从标准来讲domReady的状态为“interactive”时意味着文档解析结束了，由于标准中描述DOM树建立结束后第一件事就是把“current document readiness”设置为“interactive”。
• .domContentLoadedEventStart 返回文档发生DOMContentLoaded事件的时间。DOMContentLoad和DOMInteractive之间差了两个步骤，其中之一是全部open elements出栈，而后去看看待运行的script list中是否有须要运行的脚本，若是有则执行，一直到这个列表为空了再触发DOMContentLoad.。须要主的是这个待运行脚本列表。有些可能在不一样浏览器中被加入进去的行为可能不一样。好比 document.write写入文档流的脚本，以及script deferr 的脚本.. 因此咱们应该知道deferr的脚本也是要他推迟domContentLoaded的，也就是咱们最经常使用的所谓domReady。
• .domContentLoadedEventEnd 文档的DOMContentLoaded事件的结束时间。所谓事件结束的时间是指若是DOMContentLoaded事件被开发者注册了回调事件，那么这个时间的End时间减去Start的时间就会是这个回调执行的大概事件。固然居于部分浏览器实现可能会有2-3ms的偏差，可是这个时间基本能够忽略不计。相似的状况还有后面的.loadEventStart,End，即 window.onload 全部回调所消耗的时间。
• .domComplete 返回用户代理把其文档的“current document readiness”设置为“complete”的时候。若是current document readiness的某个状态被屡次触发那么对应的domLoading, domInteractive, domContentLoadedEventStart, domContentLoadedEventEnd and domComplete这些对应的API返回的时间就应该是这个状态第一次触发的时间。
• .loadEventStart 文档触发load事件的时间。若是load事件没有触发那么该接口就返回0。
• .loadEventEnd 文档触发load事件结束后的时间。若是load事件没有触发,那么该接口就返回0。

因为使用的是HTML5技术，因此目前支持的浏览器有限，具体详情可查看这里。

另外除了HTML5提供的接口之外，Chrome还提供了另一套是有的方法：chrome.loadTimes()

上面的数据也可用来作性能的监测。