现在已经确定的HTTP/2规范理所当然地吸引了web性能社区的大量兴趣。新协议旨在解决老化的HTTP/1常见的网络性能问题。X协议，同时保留现有的语义。
今年早些时候，我们开始了静态资产的小规模推出。在对我们的新基础设施建立信心之后，我们开始将静态资产过渡到HTTP/2。令人惊讶的是，我们平台的某些部分感觉明显较慢。这篇文章将涵盖我们对采用HTTP/2所经历的性能倒退的调查。
我们的故事并不是通常与HTTP/2相关的web性能的万灵药。我们希望分享我们发人深省的经验将有助于平衡讨论。
为什么HTTP / 2 ?
- - - - - -
不管是好是坏，HTTP/2的故事已经与一些概念联系在一起自由的表现以及它将如何产生我们对网络性能的了解都是错误的．
实际上，HTTP/2的性能是一个细微差别。
与HTTP / 1。x为每个资源创建一个新连接，HTTP/2最多为每个主机名创建一个连接。该连接是利用二进制帧协议的多路复用流。二进制帧负责将多个并发请求与响应进行匹配。
不再局限于每个连接一个事务，head-of-line阻塞在很大程度上消除。创建更少的连接也意味着降低对延迟和TCP拥塞控制的敏感性。结合起来，这些属性可以带来很大的性能优势，因为它们减少了服务器和客户机之间的往返的量和时间。
监控HTTP/2协议的性能
- - - - - -
我们使用口径为了对最终用户的性能进行综合监控，收集一组不同的指标。我们将这些数据的一小部分推送到整个办公室高度可见的壁虎板上。
我们使用以下指标作为用户感知的页面加载性能和HTTP/2是否成功的代理。我们选择这些特定的指标是因为它们受到页面加载生命周期不同方面的影响。
- DOMContentLoaded事件内被同步脚本延迟。
- 第一次粉刷的时间被渲染阻塞资源(如CSS和字体)延迟。
- 视觉上完成的时间由非呈现阻塞资源(如图像和潜在的异步脚本)延迟。
- 速度指数随时间的推移受视觉完成率的影响。
测试和验证HTTP/2是否成功
- - - - - -
我们首先将我们的图像缩略图CDN迁移到CloudFlare，它提供了开箱即用的HTTP/2。最初的基准测试显示，CloudFlare的延迟和响应时间与我们现有的CDN不相上下。
作为一个设计市场，我们的大多数页面都是以图片为中心的，通常需要超过50张图片。
使用HTTP/1.x时，连接延迟的微小变化会对具有许多小资源的页面产生不利影响。对于这种延迟受限的页面，我们期望可视化完成速度更快。快多少取决于连接延迟和图像的数量。我们预计这种趋势将在高延迟、低带宽的3G连接上持续下去。
对于带宽限制的页面，我们预计不会看到明显的变化。
仅为图像启用HTTP/2不会影响线首阻塞，所以我们不期望在第一次绘制或第一次绘制时发生任何更改DOMContentLoaded．
现实
- - - - - -
结果并不是那么明确。下面我将深入探讨HTTP/2推出的一些细微差别、惊喜和未来的考虑。
测试
我们在一个特性标志后面启用了HTTP/2 CDN，在接下来的一周中，我们记录了大约100个带有和不带有新的CDN的Calibre快照。Calibre Chrome代理位于美国，具有低延迟、高带宽连接。
案例研究:设计师作品集
设计器组合是典型的延迟限制99designs页面的代表。在这里，我们观察到速度指数和视觉完成时间提高了5%。
第一次绘制的时间是相当的，但有趣的是，初始渲染在HTTP/2中更完整。
案例研究:发现设计画廊
我们的发现设计画廊都代表了我们立场的极端。有80张图片，每页大约10mb，这些页面都是带宽限制的，所以减少延迟的效果应该是微不足道的。因此，我们预计性能不会有明显的变化。
我们实际观察到的是视觉完成和速度指数在时间上的平均回归为5-10%。但是总的页面加载时间减少了，这表明我们正受益于连接延迟的减少。
高延迟测试
用于收集我们使用的高延迟连接的数据WebPagetest使用3G连接配置文件。
最初的油漆继续更完整，但发生了明显的晚。整体页面加载继续提前进行。
与直觉相反的是，Designer配置文件和Discover配置文件的视觉完整性平均分别延迟了15%和25%。
TL;博士:
对于典型的图像丰富、延迟受限的页面，使用高速、低延迟连接，视觉完成速度平均快5%。
对于使用相同连接的图片非常多、带宽受限的页面，视觉完成速度平均要慢5-10%。
在一个高延迟、低速的连接中，我们看到页面到达视觉完成的显著延迟。
在所有的测试中，我们都看到了整体页面加载时间的提高，以及更完整的初始绘制。
的后期
- - - - - -
收集到的数据给我们留下了一个大问题:
当使用HTTP/2时，虽然加载速度更快，但带宽限制的页面要花更长的时间才能实现可视化完成。这是为什么呢?
假设1:网络饱和
HTTP / 1。由于打开了许多短命连接，X流量本质上是突发的。这种行为是负责任的网络的瀑布可以在开发工具中看到。
最初，我们认为一个长时间的TCP连接加载兆字节的图像数据可能会因为加载CSS、JS或字体等布局阻塞资源而耗尽带宽。
然而，网络瀑布并没有显示布局阻塞资源的加载行为发生任何变化。
假设2:加载优先级改变
当使用HTTP / 1。X中，浏览器对一个源同时打开的连接的限制大约为6个。当资源被发现时，它们被添加到FIFO资源下载队列中。限制到某个源的打开连接的数量会创建一个隐式的资源加载优先级。
每个排队的资源表示到原点的请求-响应往返，必须在资源离开队列之前完成。这种行为就是我们所说的网络瀑布。
HTTP/2的帧协议允许浏览器将多个请求和响应拼接在一起，因此我们丢失了文档顺序优先级队列。
我们认为HTTP/1。推杆的最佳练习脚本现在可能会对我们造成伤害。
难道我们对性能的了解都是错的吗?
然而,类似的DOMContentLoaded时代证明这种说法不成立。网络瀑布证实布局块资源优先于图像。
实际上，浏览器下载队列中的资源是有优先级的。这就是为什么开始80个图像请求之前找到脚本在页面底部不会延迟脚本的加载。
资源的确切加载行为没有记录，没有指定，并且不断变化。然而，在大多数(如果不是所有)浏览器中，图像的优先级低于CSS、JavaScript和字体。
假设3:流
没有HTTP/1的同时连接限制。X时，浏览器可以一次性加载所有80张图片。然后，服务器将同时响应所有这些图像请求，浏览器将在它们完成下载时绘制它们。我们可以从网络时间轴上确认这一行为。
目前仍在按文件顺序要求这些图像。然而，较小的图像可以更快地完成下载，因此可以更快地呈现。如果一个较大的图像碰巧在初始视口中，它将需要更长的时间来加载，延迟视觉完成。
这也解释了为什么当带宽受到更多限制时，视觉完成所需的时间更长，并且有如此大的差异。
HTTP/2的小字
- - - - - -
我们在流上遇到的问题实际上是HTTP/2的一个大特性，但很少被提及。
Ilya Grigorik最好说:
使用HTTP/2，浏览器依靠服务器以最优的方式传递响应数据。这不仅仅是字节数或每秒请求数，而是字节传送的顺序。非常仔细地测试你的HTTP/2服务器。”
传统上，资源是按照文档顺序请求的，浏览器会添加一些启发式方法来提高性能。这种方法存在一些大问题:
- 启发式是没有记录的
- 不同浏览器的启发式不同
- 不同浏览器版本的启发式不同
- 启发式对于所有站点都是通用的
对这些启发式的更改将导致页面性能突然改变，而没有任何警告。
HTTP/2改变了资源优先级的格局——现在责任由浏览器和服务器共同承担。浏览器会提示服务器优先级，但负责字节传送顺序的是服务器。
这种权力转移是一把双刃剑。
服务器和客户端中都存在的资源优先级启发式会使情况更加不透明和脆弱。然而，使服务器具有权威性为开发人员提供了管理的途径。
结论
- - - - - -
我们的调查发现，没有所谓的免费性能——这一点浏览器供应商早就知道了。
追求网页性能是一种权衡和细微差别。
在像我们研究的那些图片过多的页面中，选择多路复用HTTP/2连接而不是多个HTTP/1连接的临界点。X连接是当延迟接近图像的平均下载时间时。在高延迟和低带宽的正确组合下，我们可以看到HTTP/2在小图像上的巨大胜利。
HTTP/2实现很年轻，协议的表面积很大:
- 资源权重优先级
- 资源依赖优先级
- 多路复用启发式
- 流和连接流控制
我们可以期待在未来几年看到所有这些层面的调整、优化和不可避免的bug。了解新技术的动机和权衡是很重要的，这样我们才能准确地区分炒作和价值。
关于图像优化的说明
在Discover的情况下，改进的图像优化无疑会减少HTTP/1和HTTP/2用户完成可视化的时间。HTTP/2用户是否会看到更大的好处还不清楚。我们还需要考虑为我们的平台寻址图像优化解决方案所付出的努力和开销。
作为一个设计市场，我们的图像质量是一个关键的问题。我们非常小心，因为糟糕或过度优化的图像工件会对用户体验产生负面影响。
我们经常评估堆栈复杂性、处理大量预览的成本和其他用户体验改进的机会成本之间的权衡。目前，当我们研究合适的响应解决方案时，边缘缓存和低开销交付(如HTTP/2)达到了正确的平衡。
谢谢
这篇文章是可能的技术编辑由安德鲁Krespanis而且本·施瓦兹．感谢。
