在这个信息爆炸的互联网时代，越来越多的人缺少了等待的耐心，网站性能对于一个网站来说越来越重要。以下为监控到的网站打开时间对跳出率的影响：
- 当网站打开时间在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使用起来可能会比较麻烦些，有机会在详细介绍这个工具的使用方法。
2、探测类
普通测试类的网站有：
- 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/）
3、监控类
4、服务器监控
- Nagios http://www.nagios.org/
- Cacti http://www.cacti.net/
二、监控系统的现状
目前第三方监控做的较好的主要为基调网络和监控宝，其中基调网络监控的数据更加详细完整，属于高富帅产品，而监控宝相对的更加平民化些，以下是针对这两个服务的分析。
优势
- 无需改动现有程序代码。第三方监控由于采用主动访问并采集的机制，只需要在用户管理界面配置相关页面的URL，就可以模拟用户访问的过程，因而完全不需要开发人员介入。
- 能采集到丰富的数据。因为模拟访问使用的浏览器由供应商部署，所以可以在客户端加入自定义插件或集成其他性能工具，能通过编程实现各类性能数据的采集。
劣势
- 成本比较大，以基调为例，如果要做到每天，每半小时监控一次的话，假设需要监控的终点页面为20个，全国要监控50个节点，每个节点3个线路，每个线路两台电脑的话，大概费用是每天1500元。而监控宝相对于基调网络监控的数据比较单一，成本相对要低些，每年要做到基本全面监控需要花4000元。
- 监控点有限，不能覆盖整体用户群。监控点可以增加，但总是无法覆盖所有的网络环境，比如用户开着迅雷下下载内容等，因此数据只能用于参考，并不能代表真实用户感受。
- 监控有时间间隔，都是按事先设定好的频率进行监控，在间隔中间点如发生问题，无法获知，且频率与费用成正比关系，频率越高费用越高。
- 对于强依赖流程进入的页面难以监控。例如预订流程，需要POST大量信息，且有时效性，对于监测点来说具有一定的挑战。
另外除了上述两种方法，前面的文章中说到了可以用GA来统计网站打开时间。具体原理为：
在页面的头部和底部分添加
- var _nStartTime = new Date().getTime();
- var _nEndTime = new Date().getTime();
两者的时间时间差即为页面的打开时间。但是此方法有很多的弊端，仅仅是统计了用户的部分耗时，其中不包括，连接时间、DNS解析时间、首包时间等。上述统计的时间，并不能真实的反应用户的打开时间。
三、性能监控需要关注哪些指标
以下为一些指标主要针对前台页面的加载。
- 页面加载时间：从DNS解析开始到返回所有文件内容所用的时间
- DNS解析时间：网站域名通过 DNS 服务器解析到IP地址的时间
- 初始化连接时间：浏览器和WEB服务器建立TCP/IP连接的消耗时间
- 首字节时间：从发起页面请求至服务器端返回第一个字节
- 下载时间：从接收服务器发回的第一字节至主页面下载完成
- 渲染时间：从页面跳转至页面Dom元素稳定。
四、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()
上面的数据也可用来做性能的监测。
参考文章
1273
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
