在使用HTTP / 2时，缩小和连接JS / CSS文件以及使用图像精灵仍然可以提供性能优势吗？
使用新的HTTP / 2协议，重复的HTTP请求到同一台服务器所产生的开销已经大大降低了。
考虑到这一点，是否仍然有任何显着的性能优势来缩小和连接JavaScript / CSS文件，并将图像组合成精灵？ 或者当HTTP / 2被使用时，这些做法是否不再有用？
他们仍然有用。 HTTP / 2减less了这些做法的影响，但并没有消除这些影响 。
缩小仍然像以前一样有用 。 尽pipeHTTP / 2为消息头引入了新的压缩，但是与缩小无关（这是关于消息体的）。 消息体的压缩algorithm是相同的，所以缩小和以前一样节省了很多带宽。
连环和精灵的影响比以前less，但是仍然会有一些影响 。 使用HTTP / 1下载多个文件而不是单个文件最大的问题实际上并不是一个HTTP方面的问题本身 ：在单独请求每个文件时，会有一些基于带宽的开销，但是由于时间的限制当你完成一个文件，然后为下一个文件启动一个新的TCP / IP会话，然后为每个要下载的文件重复这个操作。
HTTP / 2的最大焦点是消除了基于时间的开销：HTTP / 1.1试图用stream水线来做到这一点，但它并没有在浏览器中得到体现（Presto是唯一的引擎，它是完全正确的，而Presto是死）。 HTTP / 2是另一个尝试，它改进了HTTP / 1.1的方法，同时也使得这种事情是非可选的，而且它更加成功。 它还通过压缩标题消除了一些基于带宽的开销，通过压缩标题，但它不能完全消除这种开销，并且当下载多个文件时，仍然必须做出这些请求 （作为单个TCP / IP会话的一部分，所以开销较less，但不是零）。 所以虽然连接和spriting的影响比例较小，但仍然有一些影响，特别是如果您使用多个文件。
另外一个要考虑的问题，就是串联和压缩，是压缩。 类似types的连接文件倾向于比个别文件更好地压缩 ，因为压缩algorithm可以利用连接的数据片段之间的相似性。 类似的原理适用于精灵 ：在相同文件的不同区域中放置相似的图像通常会导致较小的文件，因为图像的压缩可以利用不同区域的相似性。
这可能有点晚了，但我想指出一些应该涵盖的备选点。
首先，缩小通常会对JavaScript产生某种程度的损害，这会带来一些好处，例如阻止人们轻易分析代码，从而阻止普通用户使用冗长的方法和恶意行为，即使构build良好的网站也可能存在问题有了这个。 当然，这不能代替安全性，高级用户总是可以破译丑陋的代码。
另一个原因是，并非所有的浏览器或连接都将使用HTTP / 2，至less不会立即 – 所以如果某些HTTP / 2function的性能在HTTP / 2客户端上几乎不可见，那么为什么不利用那些通过HTTP连接/1.1？
最后，在一天结束时，确定如何影响服务器速度的最好方法是对其进行基准testing。
到目前为止，所有的答案都默认你会想要为每个页面下载所有的.CSS和.JS文件。 使用http / 2并保持.CSS和.JS文件分开的好处是，你只能拖下你需要的东西，而不下载东西总是比下载快。
是的，它仍然有用。
随着GZIP压缩，你的网页将减less重量。
想象一下你正在使用一个非常慢的GPRS（56Kbps，500ms ping）networking。
你有50个小图像，30个JavaScript和20个CSS文件。
这意味着，有两个并行连接，你只能等待超过100 * 500ms的请求。
现在，每个图像大约3-4kb。 这可能需要几毫秒（5-8？）。
现在，CSS文件和JavaScript的范围从20Kb到600Kb。
这将以巨大的传输时间杀死您的网站。
减less传输文件的时间将增加网站加载的速度。
所以， 是的 ，它仍然是有用的！
缩小JS仍然可以减less许多符号的大小; inflatedJargonSymbolizerTokenManager将成为_a 。 我发现的一个例子显示，JQuery GZipped仍然是JQuery.min GZip的两倍。
我也想指出，虽然你并不意味着其他，dystroy的评论是正确的，事实上与写得不好的Wikipedia解释相矛盾; “连接”JavaScript文件现在可能不太有用。 缩小它们仍然有其好处。 只是想提一下，如果你碰巧在那里得到一些信息。 实际上，如果我不担心编辑之战，我会自己编辑页面。
CSS可能减less符号的机会。 从理论上讲，所有它将得到的是空白和注释删除。
