也许您听说过 HTTP/2？它不仅仅是一个想法，而是一种真正的技术，并且托管公司和 CDN 服务正在缓慢但稳定地将其发布到他们的服务器上。关于使用 HTTP/2 而不是 HTTP1.x 的好处已经有很多说法，但实践出真知。
今天我们将进行一些真实世界的测试，进行一些计时，并看看我们可以从所有这些中提取出什么结果。
为什么选择 HTTP/2？
如果您还没有阅读过关于 HTTP/2 的内容，我建议您查看一些文章。有 HTTP/2 常见问题解答，它提供了所有细致的技术细节，而我自己也 撰写了一些关于 HTTP/2 的文章，在这些文章中，我试图淡化技术，主要关注 HTTP/2 的原因和方法。
简而言之，HTTP/2 的发布是为了解决 HTTP1.x 的固有问题。
- HTTP/2 使用二进制格式，而不是像 HTTP1.x 那样使用文本格式——这使得通过 HTTP/2 传输和解析数据本质上更易于机器处理，从而更快、更高效且更不易出错。
- HTTP/2 是完全多路复用的，允许同时传输多个文件和请求，而 HTTP1.x 每次只能接受一个请求/连接。
- HTTP/2 使用相同的连接来传输不同的文件和请求，避免了为每个需要在客户端和服务器之间传输的文件打开新连接的繁重操作。
- HTTP/2 内置了报头压缩，这是消除与 HTTP1.x 相关联的若干开销的另一种方式，HTTP1.x 需要从相同或多个 Web 服务器检索多个不同的资源。
- HTTP/2 允许服务器主动推送所需的资源，而不是等待客户端浏览器在认为需要时请求文件。
这些是 HTTP/2 如何优于 HTTP1.x 的最佳（如果过于简单）描述。浏览器不必再返回服务器获取每个单独的资源，而是可以一次性获取所有资源并进行传输。
HTTP/2 性能的半科学测试
理论很好，但如果我们能看到一些真实数据和 HTTP/2 相比 HTTP1.x 的真实性能改进，那就更有说服力了。我们将运行一些测试，以确定我们是否看到了性能的显著提升。
为什么我们将此称为半科学测试？
如果这是一个实验室，或者甚至是一个开发环境，我们希望在其中展示精确的结果，我们将消除所有变量，只测试相同 HTML 内容的性能，一个使用 HTTP1.x，另一个使用 HTTP/2。
然而，（我们大多数人）并不生活在开发环境中。我们的 Web 应用程序和网站在现实世界中运行，在各种合理原因导致波动发生的环境中运行。因此，虽然实验室测试很棒，并且绝对是必需的，但对于此测试，我们将进入现实世界，在一个（模拟）真实网站上运行一些测试，并比较它们的性能。
我们将使用一个默认的一页 Bootstrap 模板（Zebre）出于几个原因
- 它是当今现代网站外观的真实示例
- 它拥有相当多样化的资源集，这些资源是当今网站的典型特征，并且通常会在 HTTP1.x 环境下进行一系列性能优化
- 25 张图片
- 6 个 JS 脚本
- 7 个 CSS 文件
- 它基于 WordPress，因此我们将能够执行许多基于 HTTP1.x 的优化，以将其性能提升到极致
- 它在 1 月份由 ThemeForest 免费赠送。这真是个好时机，还有什么比使用 ThemeForest 上精英作者的高级主题更好的真实测试呢？
我们将使用由 Kinsta 托管的 WordPress 托管服务提供的全新帐户运行这些测试，我们最近发现了 Kinsta，并且发现它的性能非常好。我们这样做是为了避免共享托管帐户的压力环境。为了减少同一帐户上其他网站同时运行的外部影响，此环境将专门用于此测试。
我们使用最低的计划运行测试，因为我们只需要测试一个 WordPress 网站。实际上，与大多数托管服务不同，计划的速度/性能没有差异。较大的计划只是有更多网站的容量。然后，我们设置了我们囤积的域名之一 (iwantovisit.com) 并在其上安装了 WordPress。
我们还选择在 WordPress 上运行这些测试。
这样做的原因是为了方便起见，而不是其他任何原因。在手动 HTML 上进行所有这些测试需要相当长的时间才能完成。我们宁愿利用这段时间进行更广泛和更有建设性的测试。
使用 WordPress，我们可以启用以下插件：
- 缓存插件（尽可能消除生成时间差异）
- 组合和压缩插件，以根据 HTTP1.x 执行优化
- CDN 插件，以便在与 CDN 集成时轻松执行与 CDN 集成的 HTTP/2 测试
我们设置了 Zebre 主题并安装了几个插件。同样，这使得测试非常真实。您几乎找不到任何没有安装一堆插件的 WordPress 网站。我们安装了以下插件：
我们还导入了 Zebre 主题演示数据，以获得一个填充了大量图像的漂亮主题，使该网站成为 HTTP/2 测试的理想候选者。
我们做的最后一件事是确保已启用页面缓存。我们只想确保我们没有因页面生成时间而遭受剧烈波动。好消息是，使用 Kinsta，无需任何类型的缓存插件，因为页面缓存已完全内置到服务器级别的服务中。
最终页面看起来有点像这样
这是折叠以下内容
我们已准备好进行第一次测试。
测试 1 – HTTP1 – 启用缓存但没有其他优化
让我们开始运行一些测试，以确保我们拥有一个良好的测试环境并获得一些基线结果。
我们仅使用 WordPress 缓存运行这些测试——没有其他优化。
| 测试网站 | 位置 | 页面加载时间 | 页面总大小 | 请求数 |
|---|---|---|---|---|
| GTMetrix | 温哥华 | 3.3 秒 | 7.3 MB | 82 |
| Pingdom 工具 | 纽约 | 1.25 秒 | 7.3 MB | 82 |
显然有些问题。加载时间差异太大。哦，是的：Google Cloud 平台，美国中部服务器东部位于爱荷华州，使 Pingdom 工具的测试位置纽约比温哥华更近，从而使结果有利于纽约。
您可能知道，如果您想提高网站的性能，有一个非常简单的解决方案：将您的网站或应用程序托管在尽可能靠近访问者位置的位置。这就是 CDN 用于提高性能的相同概念。访问者与网站服务器位置越近，加载时间就越好。
出于这个原因，我们将运行两种类型的测试。一种将在托管服务和测试位置之间具有非常近的位置。对于另一种，我们将选择放大距离问题。因此，我们将进行一次跨大西洋的测试之旅，从美国到欧洲，看看 HTTP/2 优化是否会导致更好的性能。
让我们尝试在两种测试服务上找到类似的测试位置。德克萨斯州的达拉斯是一个常见的测试场所，因此我们将使用它作为物理位置靠近的位置。对于第二个位置，我们将使用伦敦和斯德哥尔摩，因为没有共享的欧洲位置。
| 测试网站 | 位置 | 页面加载时间 | 页面总大小 | 请求数 |
|---|---|---|---|---|
| Pingdom 工具 | 达拉斯 | 2.15 秒 | 7.3 MB | 82 |
这更好。让我们再运行几个测试。
| 测试网站 | 位置 | 页面加载时间 | 页面总大小 | 请求数 |
|---|---|---|---|---|
| GTMetrix | 达拉斯 | 1.6 秒 | 7.3 MB | 83 |
| Pingdom 工具 | 达拉斯 | 1.74 秒 | 7.3 MB | 82 |
| GTMetrix | 伦敦 | 2.6 秒 | 7.3 MB | 82 |
| Pingdom 工具 | 斯德哥尔摩 | 2.4 秒 | 7.3 MB | 82 |
您可能会注意到请求有一些波动。我们认为这些来自被调用的外部脚本，这些脚本有时在它们生成的请求数量上有所不同。事实上，虽然加载时间似乎变化约 1 秒，但通过查看瀑布图，我们可以看到网站上的资产交付非常一致。波动幅度很大的是外部资产（具体来说：字体）。
我们还可以清楚地看到距离如何显着影响加载时间约 1 秒。
在我们继续之前，您还会注意到我们的速度优化分数很糟糕。这就是为什么在我们的第二轮测试中，我们将进行一些速度优化。
测试 2 – HTTP1 性能优化和缓存
现在，鉴于我们知道 HTTP1.x 在处理请求方面非常低效，我们将进行一轮性能优化。
我们将在 WordPress 安装上安装来自 WPMUDEV 的 HummingBird。这是一个处理页面加载优化（不含缓存）的插件。正是我们需要的。
我们将启用大多数专注于减少请求和尽可能合并文件的优化。
- CSS 和 JS 文件的压缩
- CSS 和 JS 文件的合并
- 启用 GZIP 压缩
- 启用浏览器缓存
我们不会优化图像，因为这会完全扭曲结果。
如下所示，在优化之后，除了图像之外，其他所有内容的分数都接近完美。我们会故意不优化图像，以便保留其较大的尺寸并拥有良好的“负载”来承载。
让我们刷新缓存并执行第二轮测试。我们可以立即看到明显的改进。
不要在意 YSlow 中的 C。这是因为我们没有使用 CDN，并且一些外部资源（字体）无法被浏览器缓存。
| 测试网站 | 位置 | 页面加载时间 | 页面总大小 | 请求数 |
|---|---|---|---|---|
| GTMetrix | 达拉斯 | 1.9 秒 | 7.25 MB | 56 |
| Pingdom 工具 | 达拉斯 | 1.6 秒 | 7.2 MB | 56 |
| GTMetrix | 伦敦 | 2.7 秒 | 7.25 MB | 56 |
| Pingdom 工具 | 斯德哥尔摩 | 2.28 秒 | 7.3 MB | 56 |
我们可以看到网站有了相当不错的改进。接下来，我们将启用网站上的 HTTPS。这是设置 HTTP/2 的先决条件。
测试 3 – HTTP/2 无优化和缓存
我们将使用 Let’s Encrypt 功能来创建免费的 SSL 证书。这内置于 Kinsta 中，这意味着设置 HTTPS 应该非常简单。
生成 HTTPS 证书后，我们将使用 Really Simple SSL WordPress 插件 来强制整个网站使用 HTTPS。
此插件检查服务器上是否存在域的安全证书，如果存在，它会强制您的 WordPress 网站使用 HTTPS。确实，此插件使在您的网站上实施 HTTPS 变得轻而易举。如果您正在执行从 HTTP 到 HTTPS 的迁移，请不要忘记 执行从 HTTP 到 HTTPS 的完整 301 重定向，这样您在强制网站使用 HTTPS 时就不会丢失任何流量或搜索引擎排名。
在我们的网站上完全启用和测试 HTTPS 后，您可能需要进行一些操作才能开始通过 HTTP/2 提供资源，尽管当今大多数服务器在您运行 SSL 网站时都会直接切换到 HTTP/2。
Kinsta 运行在 Nginx 上，并在 SSL 网站上默认启用 HTTP/2，因此启用 SSL 就足以将整个网站切换到 HTTP/2。
执行配置后，我们的网站现在应该通过 HTTP/2 提供服务。为了确认网站正在 HTTP/2 上运行，我们安装了这个 方便的 Chrome 扩展程序，它可以检查我们的网站支持哪些协议。
确认 HTTP/2 在网站上正常运行后，我们可以运行另一批测试。
| 测试网站 | 位置 | 页面加载时间 | 页面总大小 | 请求数 |
|---|---|---|---|---|
| GTMetrix | 达拉斯 | 2.7 秒 | 7.24 MB | 82 |
| Pingdom 工具* | 达拉斯 | 2.04 秒 | 7.3 MB | 82 |
| GTMetrix | 伦敦 | 2.4 秒 | 7.24 MB | 82 |
| Pingdom 工具* | 斯德哥尔摩 | 2.69 秒 | 7.3 MB | 82 |
*不幸的是，Pingdom 工具使用 Chrome 39 执行测试。此版本的 Chrome 不支持 HTTP/2，因此我们无法现实地计算速度改进。我们将无论如何运行测试，因为我们可以有一个基准来进行比较。
测试 4 – HTTP/2 性能优化和缓存
既然我们已经看到了没有任何性能优化的 HTTP/2，那么最好实际检查一下基于 HTTP1 的性能优化在启用 HTTP/2 时是否会产生任何影响。
对此有两种思考方式
- 反对：为了执行旨在减少连接和大小的优化，我们正在为网站添加性能开销（服务器执行文件压缩和合并时），因此对性能有负面影响。
- 赞成：执行此类文件压缩和合并以及其他优化将无论协议如何都会提高性能，特别是压缩，它本质上是减少需要传递的资源的大小。任何性能开销都可以使用缓存来缓解。
| 测试网站 | 位置 | 页面加载时间 | 页面总大小 | 请求数 |
|---|---|---|---|---|
| GTMetrix | 达拉斯 | 1.0 秒 | 6.94 MB | 42 |
| Pingdom 工具** | 达拉斯 | 1.45 秒 | 7.3 MB | 56 |
| GTMetrix | 伦敦 | 2.5 秒 | 7.21 MB | 56 |
| Pingdom 工具** | 斯德哥尔摩 | 2.46 秒 | 7.3 MB | 56 |
**不支持 HTTP/2**
测试 5 – CDN 性能优化和缓存（无 HTTP/2）
您可能已经多次看到，实现 CDN（内容分发网络）是提高网站性能的主要方法之一。
但是，如果我们现在使用 HTTP/2，为什么仍然需要 CDN 呢？
即使在 HTTP/2 就位的情况下，仍然需要 CDN。原因是，除了 CDN 从基础设施角度提高性能（更强大的服务器来处理流量负载）之外，CDN 实际上还减少了网站最繁重的资源需要传输的距离。
通过使用 CDN，图像、CSS 和 JS 文件等资源将从（通常）物理上更靠近您的最终用户的位置提供服务，而不是您的网站托管服务器。
这具有隐含的性能优势：内容传输距离越短，网站加载速度越快。这是我们在上述初始测试中已经遇到的问题。物理位置更近的测试位置在加载时间方面表现要好得多。
对于我们的测试，我们将在 Incapsula CDN 服务器 上运行我们的网站，这是我们最近一直在为我们的网站使用的 CDN 服务之一。当然，任何 CDN 都将具有相同或类似的优势。
URL 重写：您安装一个插件或编写代码，以便 资源的地址被重写，以便它们从 CDN 而不是您的网站的 URL 提供服务。
- 典型的 CDN 有两种工作方式
- 反向代理：您进行 DNS 更改，以便 CDN 处理大部分流量。然后，CDN 服务将动态内容的请求发送到您的 Web 服务器。
| 测试网站 | 位置 | 页面加载时间 | 页面总大小 | 请求数 |
|---|---|---|---|---|
| GTMetrix | 达拉斯 | 1.5 秒 | 7.21 MB | 61 |
| Pingdom 工具 | 达拉斯 | 1.65 秒 | 7.3 MB | 61 |
| GTMetrix | 伦敦 | 2.2 秒 | 7.21 MB | 61 |
| Pingdom 工具 | 斯德哥尔摩 | 1.24 秒 | 7.3 MB | 61 |
测试 6 – CDN 性能优化和缓存以及 HTTP/2
我们将要执行的最终测试是实现所有可能的优化。这意味着我们在运行 HTTP/2 的网站上使用 HTTP/2 运行 CDN，并且已执行所有页面加载优化。
| 测试网站 | 位置 | 页面加载时间 | 页面总大小 | 请求数 |
|---|---|---|---|---|
| GTMetrix | 达拉斯 | 0.9 秒 | 6.91 MB | 44 |
| Pingdom 工具** | 达拉斯 | 1.6 秒 | 7.3 MB | 61 |
| GTMetrix | 伦敦 | 1.9 秒 | 6.90 MB | 44 |
| Pingdom 工具** | 斯德哥尔摩 | 1.41 秒 | 7.3 MB | 61 |
**不支持 HTTP/2**
不错！我们为一个 7MB 大小的网站实现了亚秒级的加载时间！如果您问我，这是一个令人印象深刻的结果！
我们可以清楚地看到 HTTP/2 对网站产生了积极的影响——当比较加载时间时，您可以看到加载时间有 0.5 秒的差异。鉴于我们在最坏情况下加载时间不到 2 秒的环境中运行，0.5 秒的差异是一个巨大的改进。
这就是我们真正希望达到的结果。
是的，HTTP/2 确实产生了真正的影响。
结论 – HTTP/2 性能分析
尽管我们尽可能地消除波动，但在我们的设置中仍然会存在一些不准确之处，但有一个非常明显的趋势。HTTP/2 更快，并且是推荐的未来方向。它弥补了 HTTPS 网站引入的性能开销。
因此，我们的结论是
- HTTP/2 在性能和网站加载时间方面比 HTTP1.x 更快。
- 压缩和其他减少所提供网页大小的方法，其带来的益处总是大于执行此“压缩”所需的开销。
- 缩短服务器与客户端之间的距离将始终带来页面加载时间性能优势，因此如果您想提高网站的性能极限，无论是否启用了 HTTP/2，使用 CDN 仍然是必要的。
您对我们的结果有何看法？您是否已经实施了 HTTP/2？您是否也看到了更快的加载时间？
我们也做了一个HTTP/2 现实检验。结果并不明确，也许是我们操作错误。我们最终可以安全地说，HTTP/2 并没有变慢。
https 由于握手过程，速度要慢得多
我认为您应该比较使用 SSL 的 http1 和 http2
我已经使用 Cloudflare 实现了 HTTP/2，并且已经针对 HTTP/2 “优化” 了我的网站。GTMetrix 和 Pingdom 没有给我一个好的分数（CSS 没有合并等），但是我在WPT 和 dareboost 上获得了非常好的分数，因为它们进行了 HTTP/2 测试。
HTTP/2 似乎比 HTTP/1.1 不安全。http://thehackernews.com/2016/08/http2-protocol-security.html
非常好的文章，我很高兴 HTTP/2 正在获得更多来自非谷歌这样大型公司的真实世界测试。
我的一个烦心事是，当人们输入“7Mb”时，他们指的是“7MB”：一个比特是字节的八分之一，因此 B 是否大写很重要。您可以删除此评论，版主。
仅供参考，使用 http2 合并文件是不推荐的，由于窗口大小的限制，多路复用大量较小的文件速度更快。
另外，仅供参考，我已将 Kinsta 与其推荐网站进行了对比，他们声称获得的速度（例如 0.4 秒加载时间等）实际上并非如此，他们的网站加载时间普遍接近 2.5 秒。每月 100 美元可以获得更好的服务。
很棒的文章，我感谢您为一致地测量所有内容所付出的努力。
但是……来自澳大利亚，大多数人没有美国那样的网速，我希望看到在家庭或办公室网络连接上运行相同的测试，即真实网络连接的真实测试，而不是服务器到服务器的测试（据我所知，GTMetrix 和 Pingdom 在高端服务器上运行其测试，这些服务器使用高速网络连接……）。
我不相信很大一部分真实用户实际上会让您的网站在 1 秒内完全加载——我从未体验过这种情况，无论是在任何现代网站上（浏览器缓存为空的情况下）。
我想检查一下您的网站http://www.iwanttovisit.com从我的（非常典型的澳大利亚）网络连接加载需要多长时间，以比较结果，但该网站现在已离线。
因此，我检查了加载 css-tricks.com 上的这个网页需要多长时间……它也使用 HTTPS 和 CDN 以及 HTTP2——根据我的浏览器的瀑布图（浏览器缓存为空），结果是相当一致的12 秒。
与 1 秒相比，12 秒非常长。
仅供参考：speedtest.net 将我的 ping 值评定为 20 毫秒，下载速度为 7.93 Mbps，上传速度为 0.89 Mbps，根据 speedtest.net，这在澳大利亚大约是平均水平，根据同一网站，在全球范围内也大约是平均水平。
我非常想知道您从您的连接加载此网页需要多长时间…… :)
显然，这项研究付出了很多努力，为此表示敬意。尽管如此，它的价值远不如它本可以达到的那么高。原因如下
我浏览了整篇文章，但没有发现任何关于测试客户端详细信息的说明，这在合成服务器端测试工具中也很重要。在不知道测试客户端的基本详细信息（如带宽、延迟等）的情况下，这些数字几乎没有意义。为了进一步说明这一点，我们称为“3G”的带宽类别存在 20 倍的差异。客户端详细信息的微小差异会产生截然不同的数字。
在不知道客户端详细信息并查看数字的情况下，我不得不假设这是一个类似桌面的测试。这是一种过时的做法。在所有情况下这都不是错误的，但在现代性能测试中，普遍共识是进行压力测试，这意味着使用高延迟的慢速 3G。针对这种情况进行优化可在所有方面实现黄金标准。这也是优化效果被放大且最容易分析的领域。这也是在桌面测试中 HTTP/1 和 2 之间的差异通常令人失望的原因。
您使用的所有三个指标在确定网站加载速度方面都没有用。现代需要关注的指标是首次绘制、首次有意义的绘制、速度指数……与网站渲染相关的指标。网站可能渲染速度很快，但加载时间却很糟糕。网站渲染速度可能很慢，但加载时间却很好。您完全忽略了渲染路径。
我认为您的一些测试是不必要的。并非错误，但它们使情况复杂化。已经充分证明，基本的 HTTP 优化和 CDN 有利于性能。它们应该成为 HTTP/1 和 HTTP/2 的起点，以便进行清晰的同类比较。
关于 HTTP/2 的最终结论对我来说过于草率。它也过于笼统。您基本上是在说“是的，它更好”。分析在哪里？为什么它更好？瀑布图在哪里？它过于笼统，因为 HTTP/2 的优势（更好地利用连接）在带宽受限的情况下会失效。因此，在这种情况下，它对您来说更好。但有很多假设和但是。如前所述，页面加载时间更好并没有意义，因为页面加载时间不是我们应该测量的指标。
我希望我的大量批评不会让您不快，我怀着良好的意图。我知道这不是一项科学研究，但它存在如此多的缺陷，以至于数字和结论都几乎没有意义。
我还有一个问题（可能有点偏离主题），由于 HTTP/2 不建议合并文件，我正在考虑将一个大型 css 文件分成几个较小的文件，这种特殊的 HTTP/2 实现会损害搜索引擎排名吗？
Google 审计（来自 Chrome 开发者工具）仍然要求在我的网站上合并文件。
如果有人了解此事，请随时向我发送文章或资源，其中明确指出了这一点。非常感谢。