序言
今日课后该文由ThoughtWorks@蓝属征稿撷取。
@蓝属，ThoughtWorks 高阶后端开发技师，爱好撷取，著眼后端。个人网志：https://blog.liyaodong.com
节录从这开始～～
当你短萼按照网路上的操控性强化的讲义操作方式了几番之后，你得意洋洋的觉得中文网站读取一定比以前更慢了。然而实际上是这模样的吗？
为什么他们须要测度操控性强化？当他们说起操控性强化的时候常常过多的注意到了有什么样措施能让操控性显得更快，例如填充混为一谈你的 CSS/JS，内存你的动态天然资源之类。但那些操作方式真的有效率吗？你怎样保证那些操作方式是有效率的？
我能锁上应用程序控制面板，直接看 network 工具栏。
你看，这个天然资源的允诺比之前快了1秒！！！
不对！快了四分钟！！！
好像不太稳定，ZR19的模样但最慢能快2秒呢！！！小华此为说道。
是的，当你在应用程序开发人员辅助工具锁上 network 查阅浏览速度时你会发现确实那个天然资源减慢了，但或者说的使用者到底是否感觉到快了一些？那个更动对于使用者裸眼由此可见的影响又有什么样？此项天然资源读取减慢了那其他天然资源呢？是不是减慢？
小华默默地的锁上了控制面板，陷于了思索中。
即便操控性强化整件事情不是技师的自嗨，而是或者说为终端使用者著想。
怎样测度操控性强化总而言之锁上自己应用程序的开发人员辅助工具对各种天然资源的浏览配得上是一种意义上的测度，但单个使用者，单个天数的量测无法达到他们所需的精确度。
所以你须要的是数个使用者、数个互联网环境、甚至数个自然环境下的数个天数的数次量测才能得到相对精确的结果。而这样的测试他们常常称作 Synthetic Testing。
Synthetic Testing – 测试数据量测不要被那个洋文吓到，其实就是说你不管通过某种方式主动的找了台机器访问了一下你的中文网站，记录了一些数据甚至录下了一个视频。然后你拿着那些数据开始分析你的中文网站。为了增加数据的精确度，市面上的 Synthetic 服务一般允许你设置数个节点，例如你的使用者主要在东亚你能设置北京、日本、香港、新加坡四个节点来定期做数据统计。能是每天12点夜深人静的时候测5次，当然也能选择不同的操作方式系统和应用程序环境，方便你针对不同的应用程序数据进行分析。
如果你已经迫不及待的开始想要测试你的中文网站，你能选择那个权威又免费的辅助工具先爽一把 webpagetest.org。
能看到一个典型的测试结果会告诉你，你的中文网站 Load Time 是多少秒，Speed Index 又是多少之类。右上角还有一些评分，能看到你的综合情况等。除此之外你还能自定义操控性测试机器所在的地理位置以及应用程序类型等。
当然除了 Page Speed Test 还有一个辅助工具你可能已经听说过了，叫 Lighthouse。同 webpagetest 一样也属于 Synthetic 的一种，除了能看到一些操控性指标的结果之外你还能看到一些改进建议，非常方便。
上面这两个辅助工具已经足够强大了，但可能你在想我怎样自动化的持续的去做操控性测试。一方面你能使用这两个辅助工具对应的 API，自行搭建测速节点。这须要你有多台服务器分布在不同地点。当然除此之外也有现成的服务能直接使用，例如 SpeedCurve。
总结来说 Synthetic Testing 已经是比较成熟的操控性强化方案了，那是不是说他们有了 Synthetic Testing 就大功告成了？
RUM(Real User Monitoring) – (真实使用者数据监测)Synthetic Testing 通常是你作为中文网站主主动去量测的，而且是模拟了固定的屏幕尺寸、操作方式系统、应用程序类型在固定的天数点。有可能你的中文网站在你所覆盖的 Synthetic Testing 表现都很好但实际情况下远在新西兰的 IE 使用者锁上你的中文网站须要耗费超过一分钟的天数。这也就是真实使用者数据量测(RUM)的意义所在，帮助你理解在真实的使用者体验下，你的中文网站操控性是怎样的。
RUM 的工作原理是往你的中文网站插入一小段脚本，当有真实使用者浏览你的中文网站时这段脚本便会运行，从而通过 Javascript 收集使用者的应用程序、操作方式系统、页面读取时间等相关信息。如果你用过 Google Analytics 类似的数据分析辅助工具其原理大致相同。
有什么样指标是最重要的当他们在了解重要的指标之前，先来大概了解一下应用程序的读取过程。
上图中 Navigation Start 代表你的应用程序收到了你想要跳转网页的允诺，可能是你在地址栏输入了链接并敲下了回车，也可能是你点击了某个链接发生了跳转。从那个事件开始便是应用程序尝试去解析 DNS，你的服务器端收到允诺进行对应的数据库查询或是相关操作方式并返回 HTML。
在那个过程中一个重要的指标便是 TTFB。
TTFB(Time To First Byte)
即从 Navigation Start 开始后你的应用程序接受到了第一个字节，意味着对于第一个允诺必要的 DNS、HTTPS 握手结束，并且你的后端已经完成了相应操作方式返回了对应的 HTML。如果 TTFB 的数据不理想通常意味着你的后端应用程序须要进行强化，可能是对中文网站进行动态化以减少数据库压力，也可能是数据库查询出现瓶颈，更多的问题须要像 New Relic 这样的专业工具去分析。
在应用程序收到第一个字节之后下一个重要的里程碑便是 Start Render。
Start Render 应用程序开始渲染一些东西了
他们知道应用程序在读取的过程中有很多因素是阻止应用程序进行渲染的，例如在<head> 标签中嵌入的 <script> (没有 async/defer标签的情况下)，又或是你的 CSS 文件太大没有读取完成等。Start Render 指标标明了使用者现在开始能看到一些内容开始读取了，而不是一片纯白的屏幕。
First CPU Idle 第一次 CPU 空闲，还有一个类似的指标即 Time To Interactive(TTI)
通常应用程序会使用主线程来做页面布局、垃圾回收以及解析执行 JS 的工作。如果你的 JS 文件庞大，须要消耗 CPU 大量的天数来解析，那那个指标则能很好的显示出那个问题。这时候你须要做的可能是减少 JS 文件的体积、删除无用的 CSS/JS 等。
除了以上的三个指标之外还有很多其他的指标，不同的指标类型标明了不同的问题，不过我建议在开始其他指标之前先熟悉并统计以上的三个指标。
把指标做成统计图当他们收集了足够的指标数据时，他们可能会想要做一个漂亮的数据统计图。方便告诉别人你的中文网站读取速度怎样。此时你可能会说，我的中文网站平均 2s 即可读取完毕。但平均 2s 那个数值可能并不能反映出或者说的问题所在，有可能70%的使用者都是在 1.8s 内读取完毕的，但又 20% 的使用者读取天数在 5s 甚至 8s。作为一个操控性报表你可能更多的想要看到问题在哪而不是大家平均读取速度怎样。因此常见的操控性统计报表有以下三个方法：
平均值
中位值
第95百分位值
平均值的计算方法相信每个人都很清楚了，中位值即对数据进行排序，在总样本的 1/2 处所在的操控性数据。那第95百分位值又是怎样计算出来的呢？
95百分位值即对数据进行排序，找出第 95% 处的数据，通常那个数据都是整个数据集中垫底的数据，既能帮你放大问题所在还能让你体验到使用者群中最“弱势”的使用者感受（可能是设备操控性不好或互联网较差）。如果你能保持那个值的相对稳定和强化，那基本上代表了你的系统有较好的稳定性和操控性。
为什么我的强化对整体读取效果不佳当你满腔热血的对 CSS 进行了强化，裁剪并填充了图片，使用了更快的填充算法却发现你的 First CPU Idle 只强化了 0.1s。那个时候难免有些丧气。但实际上这却是正常的。
并不是你的每处强化都会对系统带来巨大提升，正如你的系统出问题的时候也不一定全盘皆输。
Amdahls law – 阿姆达尔定律在读 CSAPP 这本书的时候读到了那个定理，即你对系统某处操控性的强化对系统整体的作用取决于该处在系统中的重要性以及你提升了多大。举个例子：
你的网页读取原本须要 10s，CSS 解析占用了 2s。
你作出了一定的强化，即将 CSS 的解析天数缩短了一半，但你的网页读取速度并没有对应的提升一半。显而易见的是你的网页强化之后的读取速度为：
10s– 2s* 0.5= 9s
// 提升了 10%
所以当你在尝试强化系统的时候能挑当前占用系统天数最长的部分下手，如果这部分已经强化到头了那就换个部分强化。因为 10s 读取一个网页你把 CSS 解析天数强化没了中文网站也只能快 2s。
关于本文 作者：@蓝属 原文：https://blog.liyaodong.com/posts/website-performance-metrics/
@蓝属曾撷取过
为你推荐
【第467期】使用者体验量测的工具：可用性测度
