转载

HTTP/2 对 Web 性能的影响（下）

一.前言

我们在 HTTP/2 对 Web 性能的影响（上）已经和大家分享了一些关于 Http2 的二项制帧、多用复路以及 APM 工具等，本文作为姊妹篇，主要从 http2 对 Web 性能的影响、http2 使用的利弊以及一些正在进行中的相关工作等方面与大家进行分享。

二.Web 性能影响：与内联、级联及图像精灵说再见？

HTTP/2 多路复用对前端 Web 开发人员造成了深远的影响。长久以来，人们用尽方法，试图通过捆绑相关资产来削减连接的数量，而现在这一切都不需要了。人们曾经尝试过的方法包括：

JavaScript 与 CSS 文件级联： 将多个小文件合成一个大文件，从而降低总体请求数量。
图像精灵： 将多个小图像合成一张大图像。
域名分片： 在多个域之间发送静态资产请求，从而增加浏览器所能允许的总体开放 TCP 连接数量。
内联资产： 将资产同 HTML 文档源绑定，包括 base-64 编码图片，以及直接写入 script 标签的 JavaScript 代码。

因为不需要再绑定资产，我们就有了更多机会将 Web 应用程序中的小片段加以缓存。举个例子可以帮我们更好的理解这一点：

一个级联且指纹验证型 CSS 文件被解绑为四个较小的指纹验证文件。

常见的级联模式是将一个应用程序内不同页面的样式表文件进行绑定，形成单一的 CSS 文件，以减少资产请求的数量。这个大文件随后会通过文件名内的 MD5 哈希值进行指纹校验，确保其能够被浏览器主动缓存。遗憾的是，这样的解决方案意味着，当站点的可视化布局中出现了任何一点小的改变，如标题字体的改变，都需要重新下载整个级联文件。

当对小型资产文件进行指纹校验时，相当一部分的 JavaScript 与 CSS 组件都不会频繁产生变动，因此可以被浏览器缓存 --也就是说，任何一个单一功能的小型重构，不会再导致大量的 JavaScript 应用程序代码或者 CSS 失效。

最后，级联机制的消失能够降低前端构建基础的复杂性。与以往通过一系列预置步骤来级联资产不同，现在它们作为小型文件，可以直接被放入 HTML 文档中。

三.实际使用 HTTP/2 的潜在弊端

仅仅针对支持 HTTP/2 客户端而做出的各类优化，意味着那些不支持 HTTP/2 的浏览器可能因此陷入不利境地。那些“有年头”的浏览器们仍然倾向于绑定资产，以此降低连接数量。截至 2016 年 2 月，caniuse.com 网站报道称，全球浏览器中能够支持 HTTP/2 的占比 71% 。与之前浏览器们决定放弃支持 IE 8.0 时一样，支持 HTTP/2 或采取某种混合作业的方式——这样的决定只能根据各个网站自身的相关数据来做出。

但是我们相信大规模支持肯定是不可避免的，就像一开始只有 Chrome 浏览器支持 window.performance 接口，方便一些 Web 工具进行数据的采集，像上面说过的Browser Insight ，我曾经和他们的技术支持聊过，就是靠这种方式来实时的采集用户对网站的访问信息等。之后，大势所趋，各个浏览器厂商都纷纷开放了相关接口

正如可汗学院的博文所述，他们曾分析其网站上的 HTTP/2 流量，事实上，拆分大量资产会增加所传输字节的总量。而使用 zlib 压缩单一大型文件，比压缩多个小型文件要更有效率。对于拥有成百上千解绑资产的 HTTP/2 站点来说，这种效应更为显著。

在浏览器中使用 HTTP/2 还要求我们通过 TLS 进行资产传递。对于菜鸟们来说，设置 TLS 证书就是个烦人的活儿。幸运的是，诸如 Let’s Encrypt 的开源项目正努力让证书注册工作变得更加便捷。

四.仍在进行中的工作

大部分用户并不在意你的站点用了啥协议——他们只想要它速度快，运行如人预期。虽然 HTTP/2 已经获得正式批准快一年了，开发人员还在学习如何利用它来建立更快速网站的最优实践。换用 HTTP/2 的好处更多取决于具体站点的架构情况以及使用现代浏览器的用户比率。再有就是，调试新协议很有挑战性，更易用的开发工具还在研制中。

虽然有这些挑战，HTTP/2 的采纳度仍在增加。根据研究人员扫描流行网站属性的结果，排名前列的站点中使用 HTTP/2 的一直在增加，特别是 CloudFlare 和 WordPress 在 2015 年宣布提供支持之后。在考虑转换到新协议时，很重要的一点是利用Browser insight 和 NewRelic 之类的 APM 工具，仔细测量资源和页面在不同环境下的加载时间。

如下图所示，可以看到每一次慢加载的详细情况，非常方便。 HTTP/2 对 Web 性能的影响（下）