通过 http/2 进行压缩的单个包与多个文件
tob*_*obi 3 css gzip bundle minify http2
关于 CSS 和 JS 捆绑的一般建议是什么：将所有内容捆绑到一个文件中更好还是提供多个文件更好？
我个人认为多个文件更好，尤其是使用 http/2，但使用 bundle 是有充分理由的：当所有内容都在一个文件中时，缩小和 gzip 会产生更好的结果，因为在编写大量代码时通常会出现所有重复. 在另一端提供多个文件可改进缓存并允许并行下载，但在可能已缩小的文件之间包含相同的代码。
是否有任何好的统计数据可以比较多个文件和捆绑文件的文件大小、压缩大小和下载时间？
Stack Overflow 上已经有几个关于这个问题的主题，但我无法找到一个尽可能多地考虑 http/2 和 minification/gzip 的主题。
以下是 http/2 的一些功能，它们减轻了串联的好处（来自高性能浏览器网络）：
将多个资产捆绑到单个响应中是 HTTP/1.x 的一项关键优化，其中有限的并行性和高协议开销通常超过所有其他问题——请参阅串联和 Spriting。然而，使用 HTTP/2，多路复用不再是一个问题，头部压缩大大减少了每个 HTTP 请求的元数据开销。因此，我们需要根据新的利弊重新考虑串联和精灵的使用：
捆绑的资源可能会导致不必要的数据传输：用户可能不需要特定页面上的所有资产，或者根本不需要。
捆绑的资源可能会导致代价高昂的缓存失效：一个组件中的单个更新字节会强制完全获取整个捆绑包。
捆绑的资源可能会延迟执行：在传输整个响应之前，无法处理和应用许多内容类型。
捆绑资源在构建或交付时可能需要额外的基础设施来生成相关的捆绑包。如果资源包含相似的内容，捆绑的资源可以提供更好的压缩。
...
HTTP/2 通过提供对请求和响应多路复用的支持消除了这种不幸的权衡，这意味着我们现在可以通过提供更细粒度的资源来优化我们的应用程序：每个资源都可以有一个优化的缓存策略（到期时间和重新验证令牌）并且单独更新而不会使包中的其他资源无效。简而言之，HTTP/2 使我们的应用程序能够更好地利用 HTTP 缓存。
我不认为重复会大大减少文件大小。此外，文件大小只是延迟和感知速度的一方面。例如，即使初始加载速度更快，当用户第二次访问时会发生什么？如果一个文件需要失效怎么办？
虽然我没有看到关于你的问题的任何具体数据，但以下是 Google 对 http/1.1 与 SPDY（http/2 的前身）的结果：
最终，您的问题的答案将是一个意见，除非有人进行一些测试以找出答案。