典型网络RTT（30-250ms）：HTTP/2比HTTP/1.x快，而且它们都比HTTPS快。美国两个相邻城市间的RTT约为30 ms，而东西海岸间（约3000英里）则约为70 ms。东京到伦敦间最短路径的RTT大约240 ms。
高RTT（300ms及以上）：HTTP/1.x比HTTP/2快，后者又比HTTPS快。
首次渲染时间
这张图显示了首次渲染的时间，也就是用户第一次在自己屏幕上看到网页内容的时间。这个时间一般认为关系到用户对网站响应速度的感知。
要想了解我们测试的更多内容，请看这个HTTP/2的介绍视频，来源是nginx.conf 2015。
然而，每个网页都不相同，实际上每个用户的会话也不一样。如果你托管流媒体或提供大文件下载，那你的决定可能不一样，甚至相反。
你最终可能发现投入产出比并不明显。如果是这样，那你得多学习一下，针对自己的内容多做一些测试，然后咱们可以聊一聊。（想找点资料？可以看看NGINX网络研讨：What’s New in HTTP/2?）。
建议二：终止HTTP/2和TLS终止协议意味着客户端使用期望的协议连接代理服务器，比如TLS或HTTP/2，然后代理服务器再去连接应用服务器、数据库服务器等，但不需要使用相同的协议，如下图所示。
终止 HTTP/2 和 TLS
配置了服务器或者虚拟服务器之后，很多事情都成为可能。新服务器可以分担其他服务器的负载，可用于负载平衡、静态文件缓存和其他用途。另外，也可以让添加和替换应用服务器或其他服务器更容易。
NGINX和NGINX Plus经常被用来终止TLS和HTTP/2协议、负载平衡。已有环境不必改动，除非要把NGINX服务器挪到前端。
建议三：考虑从SPDY开始SPDY是HTTP/2的上一代，总体性能相同。因为它已经出现好几年了，所以有很多浏览器却。不过，在本文写作时，这个支持上的差距正在缩小。具体来说，有三分之二的浏览器支持HTTP/2，而有五分之四的浏览器支持SPDY。
如果你着急采用新的Web传输协议，又想尽可能覆盖更多用户，可以先从SPDY开始。然后到2016年初，即谷歌不再支持SPDY的时候，再切换到HTTP/2，很简单，至少在NGINX中如此。那时候，更多用户会拥有支持HTTP/2的浏览器，而你已经为其中大部分用户提供了很好的性能。
建议四：找出为HTTP/1.x优化的代码在决定采用HTTP/2之前，首先得知道你的代码有哪些是针对HTTP/1.x优化过的。大概有四方面的优化。
分域存储。为了实现并行请求文件，你可能把文件分散到了不同的域里，CDN会自动这么做。但分域存储会影响HTTP/2的性能，建议使用HTTP/2友好的分域存储（参见建议七），只针对HTTP/1.x用户分域。
图片精灵（sprites）。图片精灵把很多图片拼成一个文件，然后通过代码按需取得每个图片。图片精灵在HTTP/2的环境下没太大用处，但还是有点用的。
拼接的代码文件。与使用图片精灵的原因类似，很多独立的文件也会被弄成一个，然后浏览器再从其中找到并运行需要的文件。
内联文件。CSS代码、JavaScript代码，甚至图片等被直接插到HTML文件中的内容。这样可以减少文件传输，代价是初始HTML文件较大。
后面三种优化都涉及把小文件塞进一个较大的文件里，目的是减少新建连接的初始化和握手，这些操作对TLS而言非常费时间。
第一种优化即分域存储恰恰相反，强制打开多个连接，目的是并行地从不同的域获取文件。这两种看似矛盾的技术对于HTTP/1.x下的站点却十分有效。然而，要用好这两种技术，必须投入大量时间、精力和资源，用于实现、管理和运维。
在采用HTTP/2之前，需要找出应用了这些优化的代码，分析一下它们会不会影响你的应用设计和工作流程。这样在迁移到HTTP/2之后，就可以着手改造它们，甚至撤销某些优化。
建议五：部署HTTP/2或SPDY