一个应用性能的最终判定者是该应用的最终用户。开发人员可以根据某些操作的运行时间或创建的对象实例的数量来度量应用性能。但是，这些度量标准最终用户并不care，他们有一套自己的评判标准，比如应用是否能顺利地执行，是否能快速响应？动画/音频是流畅还是断断续续？运行此应用，电池是否很快耗尽？等等等等。
(开发人员测量的实际性能和用户感知到的性能——白天不懂夜的黑)
我们把用户实际体验到的性能称之为用户感知性能。我们认为，性能调优必须最终都能反应到用户感知性能的提升，任何不以提高用户感知性能为目的的调优都是耍流氓！
用户感知性能最直接的指标是访问速度的快慢，从用户输入网址按下回车键到看到网页，这个过程的快慢是用户对一个应用性能好坏最直观的判断。我们有必要精准的还原这个过程，因为这决定了我们怎么去做性能优化。
那么，如何精准的还原从用户输入网址按下回车键到看到网页的这整个过程？
我们首先从数据传输层面来看看，从按下回车键后到看到网页，这中间都发生了什么？
整个过程，我们可以分为三段：
1、第一段在用户和浏览器端，主要负责发出用户请求，以及接受响应数据进行计算渲染显示给用户；
2、第二段在网络上，负责对请求数据、响应数据的传输；
3、第三段在网站服务器端，负责对请求数据进行处理（执行程序、访问数据库、文件等），并将结果返回；
当然我们还可以更细分一点，比如第一段又可以分为…但是等等，时刻谨记以用户感知为宗旨，这些看不见的过程用户关心吗？
NO！用户根本不care，用户只会关心他看到了什么。比如，用户输入某东主页按下回车键之后，他看到了什么？这才是他关心的。（有同学会问：这个有办法监测吗？当然有！主动检测，被动检测， 你想怎么测都可以，这个晚点再唠）
以下是性能极客记录到的用户从输入某东主页面按下回车之后看到的页面加载过程：
系统综合分析的结果是7.36秒：从按下回车键，7.36秒之后用户会觉得页面加载完成（7.36秒已经不错了，给某东技术赞一个）。
好了，截止到目前已经成功了一半，如果你是某东的技术，知道了用户看到的是什么那么以后，接下来你要做什么？
找问题咯！以这个加载过程为基础，在更小的时间粒度上360°无死角分析吧：
1：首字节下载时间是85ms,业界的标准是200ms内就是优！（给某东的技术赞一个！）
2：页面跳转过多
3：资源请求数过多
4：图片太大，没有压缩，大图片没有采用渐进式图片
5：css/js/html文件没有精要
6：没有设置长期缓存
7：DNS查询次数过多
8：没有在HTTP标头中指定字符集
9：服务器端静态资源没有启动压缩
10：有错误响应
…
（还有哪些指标就不一一列出来了，有兴趣的旁友们可以自己去极客君官网测测看）
把上面的指标一条一条优化下来，优化30%不成问题。
回过头来整理上面的做法，很容易看到逻辑：用户感知性能检测→瓶颈分析→各个击破的优化。So easy 哈？
接下来看另一个问题，我们要达到什么目标？
根据2/5/8原则:
小于2秒：very good
2-5秒：good
5-8秒：ok, acceptable.
大于8秒：bad…
等等...这是90年代的数据，到了21世纪的今天，人们的容忍度大大降低，2/5/8原则已经迭代到了估计version9.0：超过4秒，就会有20%的用户选择放弃，so:
小于4秒：good
大于4秒：bad
（这个标准会让很多技术头皮发麻吧？）
剩下最后一个问题了,用户感知性能的如何精准检测？（此处着重页面加载速度或者APP打开速度）
刚才小编说了，对网页来说，主动检测，被动检测都有，你想什么姿势都可以！
（先来360°解析一下这俩货的差别~~~）
方法
被动检测：页眉植入脚本或探针，当用户访问网页时，探针自动采集运行数据
主动监测：搭建环境，模拟用户去发起一个访问，然后再采集性能参数
优点
被动检测：真实用户数据，最后一公里，覆盖范围大
主动监测： 轻模式，无需硬件投入，成本小完全没有数据安全性隐私性担忧/ 可进行长期性能监控/可做到故障/性能及时预警
缺点
被动检测：需植入探针，有数据安全性和隐私性担忧
主动监测：不能事先发现问题和告警有硬件投入，成本大
对APP来说，APP测速技术哪家强？
别闹了，全球只此一家别无分店好嘛？！性能极客是业内第一个精准检测APP打开速度的产品。（终于说粗来了，小编可以圆滚滚的滚一边去了）
那个...小编的出发点绝对三观正：
1：不以提高用户感知性能为目的进行调优都是耍流氓！
2：以用户感知性能为宗旨的调优的关键是用户感知性能的检测！
Over ！