使用 HTTP/2 时，缩小和连接 JS/CSS 文件以及使用图像精灵是否仍能提供性能优势？

使用新的 HTTP/2 协议，向同一服务器重复 HTTP 请求所产生的开销已大大减少。

考虑到这一点，缩小和连接 JavaScript/CSS 文件以及将图像组合成精灵是否仍然具有任何显着的性能优势？或者当使用 HTTP/2 时这些做法不再有用？

它们仍然有用。HTTP/2 减少了其中一些做法的影响，但并没有消除它们的影响.

缩小仍然像以前一样有用。尽管 HTTP/2 引入了新的消息头压缩，但这与缩小（与消息体有关）无关。消息正文的压缩算法是相同的，因此缩小可以节省与以前一样多的带宽。

连接和精灵的影响将比以前小，但它们仍然会产生一些影响。使用 HTTP/1 下载多个文件而不是单个文件的最大问题实际上并不是 HTTP 端问题，per se: there is单独请求每个文件时会产生一些基于带宽的开销，但与完成一个文件后拆除 TCP/IP 会话、然后为下一个文件启动一个新文件并重复此操作所产生的基于时间的开销相比，它就相形见绌了对于您要下载的每个文件。

HTTP/2 最大的焦点是消除基于时间的开销：HTTP/1.1 试图通过管道来做到这一点，但它没有在浏览器中流行起来（Presto 是唯一完全正确的引擎，而 Presto 是死的）。 HTTP/2 是另一种尝试，它改进了 HTTP/1.1 的方法，同时也使这种事情成为非可选的，并且它会更加成功。它还消除了some通过压缩标头来减少发出多个请求时基于带宽的开销，但它不能完全消除该开销，并且在下载多个文件时，仍然必须发出这些请求（作为单个 TCP/IP 会话的一部分，因此开销较少，但不是零）。因此，虽然连接和分割的影响是按比例虽然较小，但仍然有一些影响，特别是当您使用很多文件时。

当涉及到串联和分割时，要考虑的另一件事是压缩。类似类型的串联文件往往比单个文件压缩得更好，因为压缩算法可以利用串联数据块之间的相似性。类似的原理也适用于精灵：将相似的图像放在同一文件的不同区域通常会产生较小的文件，因为图像的压缩可以利用不同区域中的相似性。