https://gold.xitu.io/entry/5784d620a633bd00668113fc
网站的速度影响了用户访问网站最初的体验。试想，如果一个用户，在等待了若干秒后，还是停留在白屏的状态，那么他的选择将是离开这个网站。性能统计有助于帮我们检测网站的用户体验。
这里引用百度百科中的一句话 ---- 通常一个网站，如果首屏时间在2秒以内是比较优秀的，5秒以内是可以接受的，5秒以上就不可容忍了。用户会选择刷新页面或立刻离开。
这里，有些数据需要与大家分享一下(来自FEX的统计)：
| 产品 | 性能 | 收益 |
| 延迟 400ms | 搜索量下降 0.59% | |
| Bing | 延迟 2s | 收入下降 4.3% |
| Yahoo | 延迟 400ms | 流量下降 5-9% |
| Mozilla | 页面打开减少 2.2s | 下载量提升 15.4% |
| Netflix | 开启 Gzip性能提升 13.25% | 带宽减少50% |
1、网站都有哪些指标？
1.1 首屏时间
这个指标对于大多数网站来说，非常重要。那么何为首屏时间呢？引用百度百科里的一句话，就是:
网站用户体验的一个重要指标。 指一个网站被浏览器如IE窗口上部800*600的区域被充满所需时间。
其实就是你的网页刚进入时，渲染完整个浏览器屏幕的时间。
关于是否包含首屏所有的图片下载完成。这个网上有些争议，有的同学说不包含图片，只要DOM+样式 都渲染完了，就算完成了。
笔者认为，既然是首屏，那么首屏上所有的东西都加载完成，让用户感受不到还有没完成的部分，就算完成了。
所以，综合一下，咱们的首屏时间，包括首屏的DOM元素的渲染，展现在用户第一屏幕的所有图片都完成。
其实Chrome提供开发着检查网站整个渲染过程的小公举，哦不，是小工具（如图1.1.1所示）在F12开发者工具的Network面板里面：
图1.1.1
这个是屏幕捕获的工具，可以看到整个网页的渲染过程。我们接着来深究一下上述哪个时间点是首屏时间点。
我们来一起看看百度首页的首屏情况，由于百度首页加载比较快，所以这里咱们模拟一下3G网的延迟（如图1.1.2）：
图1.1.2
我们看到，虽然在240ms的时候，网页算是被渲染出来了，但是还是有很多空白的地方。
279MS的时候，虽然框架都被渲染完成了，DOM与样式也都渲染完成了，但是我们看到图片还不完整，所以，当然也不算首屏完成了。
有的同学会说，318ms的时候，总算完成了吧，nonono，我们向后观察，就会发现还有一些元素会再被渲染出来。也就是说知道稳定之前，我们都不能算首屏完成了。
知道487 ms的时候，页面才算加载完成了。并且之后不会再发生页面的抖动了。
看完这些，相信聪明的你心里已经有数了，什么是首屏时间。
1.2 白屏时间
这个其实不多说，读者也明白，就是页面处于空白的时间。页面空白，用户就会焦躁，并且变得不耐心。影响白屏时间的多数是：DNS解析耗时+服务端耗时+网络传输耗时。
1.3 用户可操作时间
顾名思义，这项指标值得是，我们的网页用户可以使用的时间。一般来讲 domready时间，便是我们的用户可操作时间了。
1.4 总下载时间
通常指，页面总体的下载时间，所有的页面资源都下载完成。
1.5 自定义指标
由于业务不同，站长们所关心的时间必然也不同了。比如你可能是一个电商网站的站长，你关心你的第一屏商品到底展示的有多快( 通常这会带来更多的收入)，所以，你需要监控你的商品展现的时间。
2 如何统计自己网站的这些指标
如果并不想要花费精力在这些统计上，只是要小小的关注一下的话，当然可以自己打开控制台，在页面的各个阶段，将时间打印出来，亦或者是使用html5新增的接口：performance来评估一下自己的网站到底差在哪里(如图2.0.1)。
图2.0.1
但是，你的测试并不能代表所有的用户的情况。而且，你需要一个监控程序，去时刻提醒着你，现在你的网站的速度处于什么状况。
所以，对于有追求一些的站长而言，笔者在这里更建议采用用户日志，即，在自己网站的代码中，增加统计，并把统计结果发送到服务器。在服务器采集这些日志，并产生一个监控的网站。其实大可不必使用一些付费的服务，我们自己就可以轻轻松松的做一个简答的速度监控服务。
在本文的第三节，我们将会一起做一个小的速度监控服务的例子。很多站长甚至可以拿过来直接使用。接下来，我们还是针对之前我们提到过的几个指标，注意讲解统计方法：
2.1 如何统计首屏时间
其实，对于网页高度小于屏幕的网站来说，统计首屏时间非常的简单，只要在页面底部加上脚本打印当前时间即可，或者对于网页高度大于一屏的网页来说，只要在估算接近于一屏幕的元素的位置后，打印一下当前时间即可。
比如，现在你有一个简单的网页（如图2.1.1所示）：
图2.1.1
我们需要统计首屏时间的话，则需要定义一个基准，就是--什么时候用户点开的当前网页，HTML5的performance接口提供了这个时间：performance.timing.navigationStart，这个就是用户访问我们网页最开始的跳转时间了。
我们在页面开头处，将基准记下。
接下来，在大约的首屏处加上我们的统计：
我们再来看看我们的页面(如图2.1.2所示)：
图2.1.2
便有了首屏时间。
霸特，霸特。同学们不要激动的太早。我们这个首屏时间，并不没有算上图片。所以，我们得把首屏中所有图片的加载时间也算上。
以上封装的首屏时间函数，无依赖比较小巧，同学们可以直接使用于自己的项目中。这样，我们就轻轻松松的统计到了首屏时间。
2.2 如何统计白屏时间
可以在页面的head底部添加的JS代码来统计白屏时间，虽然这样做可能并不十分精准，但是也可以基本代表了首屏时间，如图2.2.1所示。
图2.2.1
2.3 如何统计用户可操作时间
前面提到过document.ready其实就可以算作我们的用户可操作时间啦。我们不妨直接试试，如图2.3.1所示：
图2.3.1
2.4 如何打印总下载时间
页面总体下载时间，使用window.onload即可，这可以帮助我们看看我们所有的资源是否拖慢网页，如图2.4.1所示：
图2.4.1
2.5 统一打印时间，更方便
我们将上述的统计合并，一个完整的统计就出来了，如图2.5.1所示：
图2.5.1
我们将这个日志发送到服务端去。
开启我们的nginx监听，并在服务端接收这条日志如图2.5.2，图2.5.3所示：
图2.5.2
图2.5.3
我们看看日志里面是不是已经多了一条了呢？
要是再加以定时任务，日志采集等功能的辅助，我们就能实时掌握自己网站的性能啦。