在这个信息爆炸的互联网时代，越来越多的人缺少了等待的耐心。站点性能对于一个站点来说越来越重要。下面为监控到的站点打开时间对跳出率的影响：
- 当站点打开时间在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、server监控
- Nagios http://www.nagios.org/
- Cacti http://www.cacti.net/
二、监控系统的现状
眼下第三方监控做的较好的主要为基调网络和监控宝，当中基调网络监控的数据更加具体完整，属于高富帅产品，而监控宝相对的更加平民化些，下面是针对这两个服务的分析。
优势
- 无需修改现有程序代码。第三方监控因为採用主动訪问并採集的机制，仅仅须要在用户管理界面配置相关页面的URL，就能够模拟用户訪问的过程。因而全然不须要开发者介入。
- 能採集到丰富的数据。由于模拟訪问使用的浏览器由供应商部署。所以能够在client增加自己定义插件或集成其它性能工具，能通过编程实现各类性能数据的採集。
劣势
- 成本比較大，以基调为例，如果要做到每天，每半小时监控一次的话，如果须要监控的终点页面为20个，全国要监控50个节点，每一个节点3个线路，每一个线路两台电脑的话，大概费用是每天1500元。而监控宝相对于基调网络监控的数据比較单一。成本相对要低些。每年要做到基本全面监控须要花4000元。
- 监控点有限，不能覆盖总体用户群。监控点能够添加，但总是无法覆盖全部的网络环境，比方用户开着迅雷下下载内容等。因此数据仅仅能用于參考。并不能代表真有用户感受。
- 监控有时间间隔。都是按事先设定好的频率进行监控，在间隔中间点如发生故障，无法获知。且频率与费用成正比关系。频率越高费用越高。
- 对于强依赖流程进入的页面难以监控。比如预订流程。须要POST大量信息，且有时效性，对于监測点来说具有一定的挑战。
另外除了上述两种方法，前面的文章中说到了能够用GA来统计站点打开时间。
详细原理为：
在页面的头部和底部分加入
- var _nStartTime = new Date().getTime();
- var _nEndTime = new Date().getTime();
两者的时间时间差即为页面的打开时间。可是此方法有非常多的弊端，不过统计了用户的部分耗时，当中不包含，连接时间、DNS解析时间、首包时间等。
上述统计的时间，并不能真实的反应用户的打开时间。
三、性能监控须要关注哪些指标
下面为一些指标主要针对前台页面的载入。
- 页面载入时间：从DNS解析開始到返回全部文件内容所用的时间
- DNS解析时间：站点域名通过 DNS server解析到IP地址的时间
- 初始化连接时间：浏览器和WEBserver建立TCP/IP连接的消耗时间
- 首字节时间：从发起页面请求至server端返回第一个字节
- 下载时间：从接收server发回的第一字节至主页面下载完毕
- 渲染时间：从页面跳转至页面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 (用户通过后退button訪问本页面)
- 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 返回用户代理向serverserver请求文档開始建立连接的那个时间。假设此连接是一个长连接又或者直接从缓存中获取资源（即没有与server建立连接）则返回domainLookupEnd的值。
- .connectEnd 返回用户代理向serverserver请求文档建立连接成功后（注意。不是断开连接的时间）的那个时间。假设此连接是一个长连接又或直接从缓存中获取资源 （即没有与server建立连接）,则返回domainLookupEnd的值。假设连接建立失败而用户代理进行重连则connectStart和connectEnd则应该是这次重连的相关的值。当中connectEnd必须包含建立连接的时间以及SSH握手协议和SOCKS认证等时间。
-
.secureConnectionStart 可选特性。用户代理假设没有相应的东东就要把这个设置为undefined，假设有这个东东而且是HTTPS协议那么就要返回開始SSL握手的那个时间。
假设不是HTTPS那么就返回0。
-
.requestStart 返回从server、缓存、本地资源等開始请求文档的时间。
假设请求中途连接断开了而且用户代理进行了重连并又一次请求了资源。那么requestStart就必须为这个新请求所相应的时间。
- .responseStart 返回用户代理从server、缓存、本地资源中接收到第一个字节数据的时间。
- .responseEnd 返回用户代理接收到最后一个字符的时间。和当前连接被关闭的时间中更早的那个。相同文档可能来自server、缓存、或本地资源。
- .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()
上面的数据也可用来做性能的监測。
參考文章