46

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

考虑到这一点，缩小和连接 JavaScript/CSS 文件以及将图像组合成 sprite 是否仍有显着的性能优势？还是在使用 HTTP/2 时这些做法不再有用？

4

5 回答 5

49

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

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

Concatenation 和 sprites 的影响将比以前小，但它们仍然会产生一些影响。使用 HTTP/1 下载多个文件而不是单个文件的最大问题实际上并不是 HTTP 方面的问题：在单独请求每个文件时存在一些基于带宽的开销，但与基于时间的相比相形见绌当您完成一个文件时断开 TCP/IP 会话的开销，然后为下一个文件启动一个新的，并为您要下载的每个文件重复此操作。

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

在连接和拆分方面，要考虑的另一件事是压缩。相似类型的串联文件往往比单个文件压缩得更好，因为压缩算法可以利用串联数据之间的相似性。类似的原则适用于精灵：将相似的图像放在同一文件的不同区域通常会导致文件更小，因为图像的压缩可以利用不同区域的相似性。

于 2015-02-20T14:36:18.640 回答
4

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

于 2017-08-30T03:21:57.570 回答
1

是的，它仍然有用。

与 gzip 压缩一起，您的页面将减轻重量。

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

你有 50 个小图像，30 个 javascripts 和 20 个 css 文件。

这意味着，对于 2 个并行连接，您必须等待超过 100 * 500 毫秒才能收到请求。

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

现在，CSS 文件和 Javascript 的范围从 20Kb 到 600Kb。

这会以巨大的传输时间杀死您的网站。

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

所以，是的，它仍然有用！

于 2015-02-20T14:04:09.723 回答
1

缩小 JS 仍然可以减小很多符号的大小；inflatedJargonSymbolizerTokenManager会变成_a. 我发现的一个例子表明 JQuery GZipped 的大小仍然是 JQuery.min GZipped 的两倍。

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

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

于 2015-02-20T14:37:25.480 回答
1

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

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

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

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

于 2017-07-20T14:56:37.950 回答