对于 CSS 和 JS 捆绑，一般建议是什么：是将所有内容捆绑到一个文件中更好，还是提供多个文件更好？
我个人认为多个文件更好，尤其是使用 http/2，但是捆绑有很好的理由：当所有内容都在一个文件中时，缩小和 gzip 会产生更好的结果，因为在编写大量代码时通常会出现所有重复情况。在另一端提供多个文件可以改善缓存并允许并行下载，但在可以缩小的文件之间包含相同的代码。
是否有任何好的统计数据可以比较多个文件和捆绑文件的文件大小、压缩大小和下载时间？
Stack Overflow 上已经有几个关于这个问题的主题，但我找不到一个像我希望的那样考虑到 http/2 和 minification/gzip 的主题。
以下是 http/2 的一些功能，它们减轻了串联的好处（来自高性能浏览器网络 https://hpbn.co/optimizing-application-delivery/#minimize-concatenation-and-image-spriting):
将多个资产捆绑到单个响应中是 HTTP/1.x 的一项关键优化，其中有限的并行性和高协议开销通常超过了所有其他问题 - 请参阅串联和分割。然而，对于 HTTP/2，多路复用不再是问题，并且标头压缩极大地减少了每个 HTTP 请求的元数据开销。因此，我们需要根据串联和分割的新优缺点重新考虑其使用：
捆绑的资源可能会导致不必要的数据传输：用户可能不需要特定页面上的所有资源，或者根本不需要。
捆绑的资源可能会导致昂贵的缓存失效：一个组件中的单个更新字节会强制完全获取整个捆绑包。
捆绑的资源可能会延迟执行：在传输整个响应之前，无法处理和应用许多内容类型。
捆绑的资源可能在构建或交付时需要额外的基础设施来生成关联的捆绑包。
如果资源包含相似的内容，则捆绑的资源可以提供更好的压缩。
...
HTTP/2 通过提供对请求和响应复用的支持消除了这种不幸的权衡，这意味着我们现在可以通过提供更细粒度的资源来优化我们的应用程序：每个资源都可以有一个优化的缓存策略（过期时间和重新验证令牌），并且可以单独更新，不会使捆绑包中的其他资源失效。简而言之，HTTP/2 使我们的应用程序能够更好地利用 HTTP 缓存。
我不认为重复会大大减少文件大小。此外，文件大小只是延迟和感知速度的一方面。例如，即使初始加载速度更快，当用户第二次访问时会发生什么？如果一个文件需要失效怎么办？
虽然我没有看到有关您的问题的任何具体数据，但以下是 Google 对 http/1.1 与 SPDY（http/2 的前身）的结果：
最终你的问题的答案将是一个意见，除非有人做一些测试来找出答案。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
