如果我们发出一个较大的HTTP请求，而不是通过HTTP2发出多个较小的HTTP请求，则可以从我们的服务器获得更好的吞吐量。
据我了解，由于使用HTTP2，我们可以在一个TCP连接上多路复用多个请求，因此在性能上不会产生任何显着差异。
是的，在网络级别，一个大请求将比多个小请求更有效。这是由于发出网络请求的开销。
这也是为什么在HTTP / 1.1下建议合并CSS和JavaScript并为图像进行拼接的原因，因此发送的数据量相同，但是请求的数量却低得多。实际上，由于gzip之类的压缩方式，发送大量请求时数据量通常较小。
HTTP / 2旨在通过使用multiplexing重用单个TCP连接来降低HTTP请求的成本。从理论上讲，这将使我们放弃串联和拼写。不过，实际情况还不尽人意-通常是由于浏览器效率低下，而非HTTP / 2的错误。瓶颈刚刚转移，我们需要针对新世界优化浏览器。因此，目前仍建议一定程度的浓缩和拼写。
回到您的问题，然后是的，它应该在该网络级别上具有单一作用，实际上，如果执行此操作，则HTTP / 1.1和HTTP / 2的性能甚至可能相似。
但是，在网络级别之外，您可能会发现其他不打包为更少文件的原因。例如，如果您有一个大的JavaScript文件，则浏览器必须等待所有文件都被下载，然后才能对其进行解析，编译和运行。首先下载较小，更重要的JavaScript可能会更好。与图像拼写类似，在显示单个图像之前，您可能正在等待整个精灵文件下载。
然后有缓存含义。更改单行JS或向图像Sprite添加单个图像需要创建一个全新的大文件，这意味着无法使用较旧的文件，并且需要重新下载整个文件。
加上大文件的实现和管理可能更加复杂。它们需要一个构建步骤（可能不像许多站点那么大），并且通过CSS创建和管理图像精灵通常更加困难。
[此外，如果使用它坚持使用HTTP / 1.1，那么您可能会错过HTTP / 2的其他好处，包括HPACK header compression和HTTP / 2推送（尽管这也是more tricky to get right比最初想像的/希望的！）。
It’s a fascinating topic that I’ve spent a lot of time on，最好的建议（一如既往！）是了解技术并进行测试，测试，测试！