所以有几件事要注意。

首先值得回顾一下http / 2与http / 1.1的不同之处，在哪里有帮助，哪里不会。

Http / 2将主要受益于延迟，并且需要通过低延迟连接来下载大量资源。 还有其他一些好处，但这是主要的性能优势。

如果你请求一个页面（比如index.html），在http / 1.1下，加载10个CSS资源和10个javascript资源，浏览器会依次请求这20个资源中的每一个，等待请求从浏览器到服务器，直到它可以请求下一个资源。 服务器可能会很快得到资源（尤其是对于静态资源，如css和javascript），因此大部分时间将花费在互联网上来回传输，而不是在任何一端进行处理。 这些数字很小（例如往返100ms），但是它们会叠加多次请求（例如，本例中为2,000ms或两秒钟 – 任一侧的信号处理时间）。 浏览器试图通过向服务器打开多个请求（通常是4-6）来解决这个问题，所以当有一个请求队列（如20个请求）时，他们可以并行地取得4-6个，而不是等待每个请求完成连续。 因此，在这个例子中，我们可能能够将它分割成在4个连接中的每一个上加载20个资源中的5个，所以它们可能只花费500ms来全部下载 – 这是对单个连接的改进。 但是这是一个骗局，在建立和管理这些额外的连接方面有其自身的问题。

Http / 2旨在通过允许请求以任何顺序在单个连接上发送而不必等待响应来减少这种影响。 所以浏览器可以一个接一个地请求这20个资源，而不必等待每个资源回来。 因此，这些请求将同时在Internet上传输。 所以在最好的情况下，我们只需要等待所有20个资源的单次往返时间（100ms）。

关键在于http / 2本身对于单个资源来说不是“更快”的。 这对于许多资源来说只是更快。 在完全最佳的情况下（例如0ms的延迟），http / 1.1和http / 2请求将几乎完全相同，没有真正的性能改进。

所以，在这个理论背后，让我们指出一下你的具体情况：

1. 关于Nginx-> Node连接比Browser-> Nginx更重要。 这是因为这个连接的延迟会更糟糕（假设你的Nginx和Node位于服务器之间（或者甚至是相同的服务器），所以延迟时间最短）。 我可以想象你的Nginx-> Node连接仍然是 http / 1.1，但是这并不是一个真正的问题，也是因为Nginx将能够同时打开到不同节点服务器的多个连接（甚至多个连接到同样的节点服务器）。

2. 你在哪里测试和多少跳到您的网络服务器？ 如果在企业网络上进行测试，并且在与数据中心相同的网络上进行测试，则延迟会很低，因此改进可能不明显。 我从屏幕截图中看到，您在开发人员工具中将您的连接设置为“Wi-Fi”，但仍然可能不足以看到性能提高。

3. 延迟是您的网页/应用程序的问题？ 这可能是你的网站是如此的超级优化，以获得所需的资源，按需要的顺序，并且几乎不能跟上所有的20个请求。 然后，在任何一端处理这些请求/响应都需要时间 – 无论是在浏览器中解析并呈现CSS / JavaScript，还是在服务器中处理请求（例如因为它必须执行大量处理或连接到数据库才能返回该资源）。 所以网络延迟实际上可能不是您的网站的问题（虽然，但除了最简单的网站，这是一个问题）。

4. 如何衡量改进，鉴于http / 2仍然是相当流血的优势？ 我听说有些事实证明，Chrome开发者工具还没有准确地报告http / 2次，并且正在销售这些好处。 而其他的性能测试工具甚至可能根本不是http / 2，所以可能会回落到http / 1.1。 下面是一个http / 2测试资源的列表，但是，像Chrome开发人员工具可能做的那样，大多数对于测试您使用的是http / 2而不是其中的任何性能优势是非常有用的： https：//blog.cloudflare。 COM /工具-用于调试测试功能和使用-HTTP-2 /