当使用HTTP/2时，缩小和连接JS/CSS文件，以及使用精灵进行图像处理仍然可以提供性能优势

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

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

连接和精灵的影响将比以前小，但它们仍然会有一些影响。使用HTTP/1下载多个文件而不是单个文件的最大问题实际上并不是HTTP方面的问题，本身：在单独请求每个文件时，存在一些基于带宽的开销，但与在处理完一个文件后拆除TCP/IP会话，然后为下一个文件启动新会话的基于时间的开销相比，这是相形见绌的，并对要下载的每个文件重复此操作。

HTTP/2最大的重点是消除基于时间的开销：HTTP/1.1试图通过流水线来实现这一点，但它在浏览器中没有流行起来（Presto是唯一一个完全正确的引擎，Presto已经死了）。HTTP/2是另一种尝试，它改进了HTTP/1.1的方法，同时也使这种事情成为非可选的，而且它会更成功它还通过压缩标头消除了在发出多个请求时基于带宽的一些开销，但它无法完全消除这些开销，并且在下载多个文件时，这些请求仍然必须发出（作为单个TCP/IP会话的一部分，因此开销较小，但不是零）。因此，虽然串联和spriting的影响按比例小于em>，但仍然存在一些影响，尤其是如果您使用了许多文件。

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

到目前为止，所有的答案都默认您希望下载每个页面的所有.CSS和.JS文件。使用http/2并将.CSS和.JS文件分开的一个好处是，你只能删除你需要的文件，而不下载总是比高效下载更快。

是的，它仍然很有用。

与gzip压缩一起，你的页面重量会更小。

想象一下，您正在使用一个非常慢的GPRS（56Kbps，500ms ping）网络。

您有50个小图像、30个java脚本和20个css文件。

这意味着，对于2个并行连接，您必须等待超过100*500ms的请求。

现在，每个图像大约为3-4kb。这可能需要几毫秒（5-8？）。

现在，CSS文件和Javascript的大小从20Kb到600Kb不等。

这将扼杀你的网站与巨大的转移时间。

减少传输文件的时间将提高网站加载的"速度"。

所以，是，它仍然有用！

最小化JS仍然可以减少许多符号的大小；CCD_ 1将变为CCD_。我发现的一个例子显示JQueryGZipped仍然是JQuery.min GZipped的两倍大。

我还想指出的是，虽然你没有其他暗示，但dystroy的评论是正确的，事实上与维基百科糟糕的解释相矛盾；"串联"JavaScript文件现在可能不那么有用了。将它们最小化仍然有好处。我只是想提一下，以防你碰巧在那里得到一些信息。事实上，如果我不担心陷入编辑战，我会自己编辑页面。

CSS减少符号的机会可能更少。从理论上讲，它只会得到空白和注释删除。

这可能有点晚了，但我想指出一些应该涵盖的替代点。

首先，缩小通常会对JavaScript进行某种丑化，这在带宽之外也有好处——它防止人们轻松分析代码，防止普通用户使用冗长的方法和想法进行恶意操作——即使是构建良好的网站也可能存在问题。当然，这并不能代替安全性，高级用户总是可以破译不合格的代码。

另一个是，并非所有浏览器或连接都将使用HTTP/2，至少不会立即使用。因此，如果某些HTTP/2功能的性能在HTTP/2客户端上几乎不明显，为什么不让那些仍然通过HTTP/1.1连接的浏览器或连接受益呢？

最后，在一天结束时，确定任何事情如何影响服务器速度的最佳方法是对其进行基准测试。