在这个信息爆炸的互联网时代，愈来愈多的人缺乏了等待的耐心。站点性能对于一个站点来讲愈来愈重要。下面为监控到的站点打开时间对跳出率的影响：javascript
- 当站点打开时间在0-1秒时，跳出率为12%
- 当站点打开时间在1-2秒时，跳出率为26%
- 当站点打开时间在2-3秒时，跳出率为30%
从上面的数据很是明显的可以看到站点的打开速度对用户体验或者站点信任度的影响会产生多大的影响。html
1、怎样监控站点的性能html5
一、工具类java
这部分主要介绍的是站点性能的检測工具。工具类的监控主要长处是调试方便，缺点就是不能准确的或者用户的真实訪问数据。详细的工具备：ios
- Google Page Speed https://developers.google.com/speed/pagespeed/
- Google Speed Tracer https://developers.google.com/web-toolkit/speedtracer/?
hl=zh-CNweb
- Yahoo Yslow http://yslow.org/
- Fiddler http://fiddler2.com/ （软件介绍）
- HttpWatch http://www.httpwatch.com/
- HTTP Analyzer http://www.ieinspector.com/
上面的工具备的免费，有点收费，但是总体的功能差点儿相同。当中Google Speed Tracer使用起来可能会比較麻烦些，有机会在具体介绍这个工具的用法。chrome
二、探測类编程
普通測试类的站点有：浏览器
- 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/）
三、监控类
四、server监控
- Nagios http://www.nagios.org/
- Cacti http://www.cacti.net/
2、监控系统的现状
眼下第三方监控作的较好的主要为基调网络和监控宝，当中基调网络监控的数据更加具体完整，属于高富帅产品，而监控宝相对的更加平民化些，下面是针对这两个服务的分析。
优点
- 无需修改现有程序代码。第三方监控由于採用主动訪问并採集的机制，仅仅需要在用户管理界面配置相关页面的URL，就可以模拟用户訪问的过程。于是全然不需要开发者介入。
- 能採集到丰富的数据。因为模拟訪问使用的浏览器由供应商部署。因此可以在client增长本身定义插件或集成其它性能工具，能经过编程实现各种性能数据的採集。
劣势
- 成本比較大，以基调为例，若是要作到天天，每半小时监控一次的话，若是需要监控的终点页面为20个，全国要监控50个节点，每个节点3个线路，每个线路两台电脑的话，大概费用是天天1500元。而监控宝相对于基调网络监控的数据比較单一。成本相对要低些。每一年要作到基本全面监控需要花4000元。
- 监控点有限，不能覆盖整体用户群。监控点可以添加，但老是没法覆盖所有的网络环境，比方用户开着迅雷下下载内容等。所以数据仅仅能用于參考。并不能表明真有用户感觉。
- 监控有时间间隔。都是按事先设定好的频率进行监控，在间隔中间点如发生故障，没法获知。且频率与费用成正比关系。频率越高费用越高。
- 对于强依赖流程进入的页面难以监控。好比预订流程。需要POST大量信息，且有时效性，对于监測点来讲具备必定的挑战。
另外除了上述两种方法，前面的文章中说到了可以用GA来统计站点打开时间。
详细原理为：
在页面的头部和底部分加入
- var _nStartTime = new Date().getTime();
- var _nEndTime = new Date().getTime();
二者的时间时间差即为页面的打开时间。但是此方法有很是多的弊端，不过统计了用户的部分耗时，当中不包含，链接时间、DNS解析时间、首包时间等。
上述统计的时间，并不能真实的反应用户的打开时间。
3、性能监控需要关注哪些指标
下面为一些指标主要针对前台页面的载入。
- 页面载入时间：从DNS解析開始到返回所有文件内容所用的时间
- DNS解析时间：站点域名经过 DNS server解析到IP地址的时间
- 初始化链接时间：浏览器和WEBserver创建TCP/IP链接的消耗时间
- 首字节时间：从发起页面请求至server端返回第一个字节
- 下载时间：从接收server发回的第一字节至主页面下载完毕
- 渲染时间：从页面跳转至页面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 (用户经过后退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()
上面的数据也可用来作性能的监測。
參考文章