【第1878期】网站性能优化之度量篇

　　【第1878期】网站性能优化之度量篇

　　前言

　　今日早读文章由ThoughtWorks@晓风投稿分享。

　　@晓风，ThoughtWorks 高级前端开发工程师，热爱分享，专注前端。个人博客：

　　正文从这开始～～

　　当你快刀斩乱麻按照网上的性能优化的教程操作了一番之后，你洋洋得意的觉得网站加载一定比以前更快了。然而事实上是这样子的吗？

　　为什么我们需要度量性能优化？

　　当我们谈起性能优化的时候往往过多的注意到了有哪些措施可以让性能变得更好，例如压缩混淆你的 CSS/JS，缓存你的静态资源等等。但是这些操作真的有效吗？你如何保证这些操作是有效的？

　　我可以打开浏览器控制台，直接看 network 选项卡。

　　你看，这个资源的请求比之前快了1秒！！！

　　不对！快了半秒！！！

　　好像不太稳定，时快时慢的样子但是最快可以快2秒呢！！！小明如是说道。

　　是的，当你在浏览器开发者工具打开 network 查看网速时你会发现确实这个资源变快了，但是真正的用户究竟是否感觉到快了一些？这个改动对于用户肉眼可见的影响又有哪些？这项资源加载变快了那其他资源呢？有没有变慢？

　　小明默默的关上了控制台，陷入了沉思中。

　　毕竟性能优化这件事情不是工程师的自嗨，而是真正为终端用户着想。

　　如何度量性能优化

　　诚然打开自己浏览器的开发者工具对各种资源的下载算得上是一种意义上的度量，但是单一用户，单一时间的测量无法达到我们所需的准确性。

　　所以你需要的是多个用户、多个网络环境、甚至多个地理环境下的多个时间的多次测量才能得到相对准确的结果。而这样的测试我们往往称之为 Synthetic Testing。

　　Synthetic Testing - 试验数据测量

　　不要被这个洋文吓到，其实就是说你不管通过某种方式主动的找了台机器访问了一下你的网站，记录了一些数据甚至录下了一个视频。然后你拿着这些数据开始分析你的网站。为了增加数据的准确性，市面上的 Synthetic 服务一般允许你设置多个节点，例如你的用户主要在东亚你可以设置北京、日本、香港、新加坡四个节点来定期做数据统计。可以是每天12点夜深人静的时候测5次，当然也可以选择不同的操作系统和浏览器环境，方便你针对不同的浏览器数据进行分析。

　　如果你已经迫不及待的开始想要测试你的网站，你可以选择这个权威又免费的工具先爽一把 。

　　可以看到一个典型的测试结果会告诉你，你的网站 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。

　　即从 Navigation Start 开始后你的浏览器接受到了第一个字节，意味着对于第一个请求必要的 DNS、HTTPS 握手结束，并且你的后端已经完成了相应操作返回了对应的 HTML。如果 TTFB 的数据不理想通常意味着你的后端应用程序需要进行优化，可能是对网站进行静态化以减少数据库压力，也可能是数据库查询出现瓶颈，更多的问题需要像 New Relic 这样的专业工具去分析。

　　在浏览器收到第一个字节之后下一个重要的里程碑便是 Start Render。

　　我们知道浏览器在加载的过程中有很多因素是阻止浏览器进行渲染的，例如在 标签中嵌入的