使用 HTTP2/SPDY 时我应该缩小和连接 javascript 和 CSS 吗？答案

【问题标题】：Should I minify and concatenate javascript and CSS when using HTTP2/SPDY?使用 HTTP2/SPDY 时我应该缩小和连接 javascript 和 CSS 吗？
【发布时间】：2014-02-22 11:48:45
【问题描述】：

鉴于 HTTP2（和 SPDY）中连接重用和多路复用的优势以及 gzip 压缩的可用性，在构建过程中添加缩小和连接步骤的努力是否合理？

【问题讨论】：

使用 HTTP2（和 SPDY）的主要好处之一是您无需担心由于多路复用和连接重用而将您的 JavaScript（或图像到 spritesheets）连接或捆绑。事实上，对于 HTTP2，将每个资源留在自己的文件中是有利的，这样每个资源都由浏览器独立缓存，这样当您更新 jquery.js 时，只需将该文件发送给客户端，而不是更大的文件捆绑的 js 文件。至于缩小，请参阅stackoverflow.com/questions/807119/gzip-versus-minify

标签： javascript css http minify spdy

【解决方案1】：

根据 Chrome 团队的 Surma 的说法，在 H2 上，您可以而且实际上应该停止捆绑，因为它无用并允许更有效的浏览器缓存：

https://www.youtube.com/watch?v=w--PU4HO9SM（时间 1:10）

我认为缩小或混淆仍然是可取的，具体取决于您的需求。

【讨论】：

一篇有趣的相关博文是blog.cloudflare.com/introducing-http2

【解决方案2】：

在通过 H2/SPDY 提供资源时，测试是决定缩小和/或连接的唯一真正方法。

HTTP/2 (H2) 背后的理念是在流上提供小型静态资源（单个多路复用 TCP 连接）。测试表明，“大多数”站点通过不连接资源（甚至不使用 CDN）来提高速度。这一切都取决于在 H2/SPDY 上提供的资源的大小。我看到一个站点的速度提高了 30% 以上，而其他站点则没有变化。

考虑到这一点，我的建议是通过最小化所有资源而不是连接它们来进行测试。我还会测试服务所有常见资源（不使用 CDN - 这也取决于您的客户所在的位置）。

资源：

【讨论】：

【解决方案3】：

是的，您仍然需要缩小和连接 js 和 css 文件，原因如下：

脚本缩小和 SPDY 压缩不一样。一个好的压缩器知道利用局部作用域并将冗长的变量名替换为压缩友好的简短重复名称。
SPDY 结合您的请求，因此您不必将脚本拼接在一起。但并非所有浏览器都支持 SPDY
SPDY 2 和 3 二进制不兼容。当浏览器支持 2 并且服务器通告 3 时，连接回退到基于 SSL 的 HTTP 1.1；根本没有 SPDY 的好处
通过一个请求加载 10 个文件仍会在服务器端产生 10 次提取。合并文件可减少磁盘 I/O。

您的问题类似于“既然机器可以运行得更快，我可以不再关心编写高效的代码吗？”

答案是否定的。不要偷懒。正确编码。

【讨论】：

我认为你断言不缩小/连接文件是“懒惰的”是没有帮助的，因为它没有上下文。如果我从头开始，我认为这是一个公平的选择，但我在一个中型遗留代码库上工作，业务利益相关者有时间压力，所以 (a) 实现这些事情并非易事，并且 (b) 没有时间/金钱去做这些事情。我喜欢做很多事情，但如果 SPDY 让我走得更远，那么我就有更大的鱼可炒了。
考虑到您不是从头开始的情况，使用任何方便改进产品的方法是有意义的，即使它是边际的。我感觉到你的痛苦。保持警惕，伙计。
minify+gzip 将提供最大的压缩；但是，要权衡缩小的好处与 javascript 构建系统的成本。如果您不使用源映射，则 Minified 可能会更快下载，但很难调试。设置和维护前端构建系统当然会产生一定的劳动量。