重新搭建性能监控体系——第一章：哪些是我们真正需要的性能指标？（李华柱）

[HuazhuLi]

涉及到性能指标的设立，工程师试图站在用户的角度，去思考，用户在使用产品的过程中，哪些指标是重要的，哪些指标可以真实地反映用户的体验。
当有这种“换位”的行为出现，就必然会有误差。在经验浅薄的我看来，用户体验并不完全是科学。
所以《７天》里面的性能指标，能够完全地／真实地反映用户体验吗？我认为，世界上不存在能够完全反映用户体验的指标。
但是，《７天》里的有些指标，的确可以被制定地更加严谨。

白屏时间如何计算？

在《７》里面，白屏时间被定义为DNS查询时间为开始，而头部资源加载为结束的这一段时间。
笔者认为这一标准不够准确，并没有考虑到前面的redirect+App cache过程所消耗的时间，而用户体验恰恰包含了这段时间。
所以，用Navigation Timing API实现的话，白屏时间＝首字节时间（responseEnd - redirectStart) + 头部加载时间。
（当然，在IE浏览器里，只有IE11 才能使用Navigation Timing API，但我们可以通过其他方法来实现，比如cookie，这在实现部分有所提及。）

首屏时间如何计算？

在性能监测上，相当一部分工程师认为，首屏时间应该等于“页面可交互时间”，但事实上，由于“性能２８条”已成为前端工程师的基本素养，所以工程师会为了用户体验，选择在后部放置<script>脚本，或者选择异步加载脚本。时至今日，TTI（Time To Interact）相对于用户体验来说，不再够精准。
所以，笔者认为，用户看到的首屏，应该是用户窗口高度的内容（特别是满足above the fold这一条件的图片）加载完成的时间。

可滚动时间

在首屏时间－可执行时间的间隔里，笔者从作为一个用户的角度出发，在加载网页的场景下，发现了一个现象，用户在检测网页是否可用时，会进行的其中一种操作是：滑动鼠标。这个操作会给笔者一种反馈：网页正在加载，而且在很短的一段时间内，网页即将加载完成。
所以笔者提出了“可滚动时间”这一指标，衡量方法是，测量加载两个单位用户窗口高度的内容的所需时间。

可交互时间

在可交互（用户可操作）这一指标内，笔者十分赞同《７天》里的测量方法：domReady事件发生的时间（因为这个时间点以后，开始绑定事件）

总下载时间

总下载时间默认可以统计onload时间，这样可以统计同步加载的资源全部加载完的耗时。如果页面中存在很多异步渲染，可以将异步渲染全部完成的时间作为总下载时间。

串解：浏览器原理／发生了什么

要理解性能检测的手段，必须要理解浏览器加载网页的相关知识：
浏览器加载网页的时候做了些什么？
1.

延伸阅读：dom加载事件