12

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

4

3 回答 3

3

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

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

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

于 2016-06-25T21:01:31.940 回答
1

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

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

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

资源：

  1. 阿卡迈
  2. 专栏作家帕特里克斯托克斯
  3. HTTP/2 101（Chrome 开发者峰会 2015）
于 2015-12-02T17:11:20.790 回答
0

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

  • 脚本缩小和 SPDY 压缩不一样。一个好的 minifier 知道利用局部作用域并将冗长的变量名替换为压缩友好的简短重复名称。

  • SPDY 结合了您的请求，因此您不必将脚本拼接在一起。但并非所有浏览器都支持 SPDY

  • SPDY 2 和 3 是二进制不兼容的。当浏览器支持 2 并且服务器通告 3 时，连接回退到基于 SSL 的 HTTP 1.1；根本没有 SPDY 的好处

  • 通过一个请求加载 10 个文件仍然会在服务器端产生 10 次获取。合并文件可减少磁盘 I/O。

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

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

于 2014-02-03T18:55:15.667 回答