使用新的 HTTP/2 协议(protocol)，对同一服务器的重复 HTTP 请求所产生的开销已大大减少。
考虑到这一点，缩小和连接 JavaScript/CSS 文件以及将图像组合成 Sprite 是否还有任何显着的性能优势？或者，当使用 HTTP/2 时，这些做法是否不再有用？
最佳答案
它们仍然有用。 HTTP/2 减少了其中一些做法的影响，但并没有消除它们的影响。
缩小仍然像以前一样有用。尽管 HTTP/2 为消息头引入了新的压缩，但这与缩小(关于消息体)无关。消息正文的压缩算法是相同的，因此缩小后节省的带宽与以前一样多。
连接和 sprite 的影响会比以前小，但它们仍然会有一些影响。使用 HTTP/1 下载多个文件而不是单个文件的最大问题实际上不是 HTTP 端问题，本身:是一些基于带宽的开销在单独请求每个文件时，但是当你完成一个文件时，拆除 TCP/IP session 的基于时间的开销相形见绌，然后为下一个文件启动一个新的，并为你想要的每个文件重复这个下载。
HTTP/2 最大的重点是消除基于时间的开销:HTTP/1.1 试图通过流水线来做到这一点，但它并没有在浏览器中流行起来(Presto 是唯一完全正确的引擎， Presto 已死)。 HTTP/2 是另一种尝试，它在 HTTP/1.1 的方法上进行了改进，同时也使这种东西成为非可选的，而且它应该会更成功。 它还通过压缩 header 消除了发出多个请求时基于带宽的开销一些，但它不能完全消除该开销，并且在下载多个文件时，仍然必须发出这些请求(作为单个 TCP/IP session 的一部分，因此开销较少，但不是零)。因此，虽然连接和 spriting 的影响按比例较小，但仍然存在一些影响，尤其是当您使用许多文件时。
在连接和 Sprite 方面，要考虑的另一件事是压缩。 相似类型的串联文件往往比单个文件压缩得更好，因为压缩算法可以利用串联数据片段之间的相似性。 类似的原则也适用于 sprite:将相似的图像放在同一文件的不同区域通常会产生较小的文件，因为图像的压缩可以利用不同区域的相似性。
关于javascript - 在使用 HTTP/2 时，缩小和连接 JS/CSS 文件以及对图像使用 sprite 是否仍然提供性能优势？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/28630108/