单个包与缩小对比多个文件在http / 2上

Question

CSS和JS捆绑的一般建议是什么：将所有内容捆绑到一个文件中是否更好？或者更好地提供多个文件？

我个人说多个文件更好，尤其是http / 2，但是捆绑包有很好的理由：当所有内容都在一个文件中时，Minification和gzip会有更好的结果，因为你写的时候通常会有所有重复很多代码。在另一端提供多个文件可以改善缓存并允许并行下载，但包含可能已缩小的文件中的相同代码。

是否有比较多个和捆绑文件的文件大小，压缩大小和下载时间的良好统计信息？

关于这个问题已经有关于Stack Overflow的几个主题，但是我无法找到一个尽可能多地考虑http / 2和minification / gzip的主题。

Answer 1

以下是http / 2的一些功能，可以减轻连接的好处（来自High Performance Browser Networking）：

  

将多个资产捆绑到单个响应中是HTTP / 1.x的关键优化，其中有限的并行性和高协议开销通常超过所有其他问题 - 请参阅连接和Spriting。但是，使用HTTP / 2，多路复用不再是问题，并且头压缩会显着减少每个HTTP请求的元数据开销。因此，我们需要根据其新的优点和缺点重新考虑串联和精灵的使用：

     

  

• 捆绑资源可能会导致不必要的数据传输：用户可能不需要特定页面上的所有资产，或根本不需要。

  

• 捆绑资源可能导致代价高昂的缓存失效：一个组件中的单个更新字节会强制完整获取整个捆绑包。

  

• 捆绑资源可能会延迟执行：在传输整个响应之前，无法处理和应用许多内容类型。

  

• 捆绑资源在构建或交付时可能需要额外的基础架构来生成关联的捆绑包。   如果资源包含类似的内容，捆绑的资源可以提供更好的压缩。

  

     

...

     

HTTP / 2通过提供对请求和响应多路复用的支持来消除这种不幸的权衡，这意味着我们现在可以通过提供更细化的资源来优化我们的应用程序：每个资源都可以具有优化的缓存策略（到期时间和重新验证令牌） ）并单独更新，而不会使捆绑中的其他资源失效。简而言之，HTTP / 2使我们的应用程序能够更好地利用HTTP缓存。

我不认为重复会大大减少文件大小。此外，文件大小只是延迟和感知速度的一个方面。例如，即使初始加载速度更快，当用户第二次访问时会发生什么？如果一个文件需要失效怎么办？

虽然我没有看到有关您的问题的任何具体数据，但以下是Google针对http / 1.1与SPDY的结果，这是http / 2的前身：

最终，你的问题的答案将是一个意见，除非有人做了一些测试才能找到答案。

Answer 2

来自Front-End Performance Checklist 2017：

  

同样，通过HTTP / 2提供资产需要对您迄今为止提供资产的方式进行重大改革。您需要在打包模块之间找到一个很好的平衡并且并行加载许多小模块。

     

一方面，您可能希望完全避免连接资产，而是将整个界面分解为许多小模块，将它们压缩为构建过程的一部分，通过“侦察”方法引用它们并将它们加载到平行。对一个文件进行更改不需要重新下载整个样式表或JavaScript。

     

但是，您可以尝试逐步加载CSS。显然，通过这样做，您正在积极惩罚HTTP / 1.1用户，因此您可能需要在部署过程中为不同的浏览器生成和提供不同的构建，这是事情变得稍微复杂的地方。您可以使用HTTP / 2连接合并，这允许您使用域分片，同时从HTTP / 2中受益，但在实践中实现这一点很困难。

     

怎么办？如果你在HTTP / 2上运行，那么发送大约10个软件包似乎是一个不错的折衷方案（对于传统浏览器来说并不算太糟糕）。尝试并衡量为您的网站找到合适的平衡点。