带有缩小功能的单捆vs通过http/2的多个文件 [英] Single bundle with minification vs multiple files over http/2
问题描述
关于CSS和JS捆绑的一般建议是什么:将所有内容捆绑到一个文件中更好还是将多个文件服务起来更好?
What is the general recommendation when it comes to CSS and JS bundling: Is it better to bundle everything into one file or is it better to serve multiple files?
我个人说多个文件更好，尤其是使用http/2时，但有充分的理由进行捆绑:将所有内容都放在一个文件中时，缩小和gzip的效果更好，这是因为编写时通常会出现所有重复出现的情况很多代码.在另一端提供多个文件可改善缓存并允许并行下载，但在可能被压缩的文件中包含相同的代码.
I personally say that multiple files are better, especially with http/2, but there're good reasons for bundles: Minification and gzip have better results when everything is in one file, because of all the recurrences you typically have when writing lots of code. Serving multiple files on the other side improves caching and allows parallel downloads, but includes equal code across files that could have been minified.
是否有比较好的统计数据可以比较多个文件和捆绑文件的文件大小，压缩大小和下载时间?
Are there any good statistics that compare file size, compression size and download times for multiple and bundled files?
关于堆栈溢出的问题已经有好几个了，但是我找不到一个我想尽可能多地考虑http/2和minification/gzip的话题.
推荐答案
以下是http/2的某些功能，这些功能可减轻级联带来的好处(来自
Here are some of the features of http/2 that mitigate the benefits of concatenation (from High Performance Browser Networking):
将多个资产捆绑到一个响应中是HTTP/1.x的一项关键优化，在HTTP/1.x中，有限的并行性和高协议开销通常超过了所有其他问题(请参阅串联和拼写).但是，对于HTTP/2，复用不再是问题，并且报头压缩大大减少了每个HTTP请求的元数据开销.因此，我们需要根据其新的优缺点重新考虑使用串联和拼写:
Bundling multiple assets into a single response was a critical optimization for HTTP/1.x where limited parallelism and high protocol overhead typically outweighed all other concerns—see Concatenation and Spriting. However, with HTTP/2, multiplexing is no longer an issue, and header compression dramatically reduces the metadata overhead of each HTTP request. As a result, we need to reconsider the use of concatenation and spriting in light of its new pros and cons:
-
捆绑的资源可能会导致不必要的数据传输:用户可能不需要或根本不需要特定页面上的所有资产.
Bundled resources may result in unnecessary data transfers: the user might not need all the assets on a particular page, or at all.
捆绑的资源可能会导致昂贵的缓存失效:一个组件中的单个更新字节会强制完全提取整个捆绑包.
Bundled resources may result in expensive cache invalidations: a single updated byte in one component forces a full fetch of the entire bundle.
捆绑的资源可能会延迟执行:在传输整个响应之前，无法处理和应用许多内容类型.
Bundled resources may delay execution: many content-types cannot be processed and applied until the entire response is transferred.
捆绑的资源可能在构建或交付时需要其他基础结构才能生成关联的捆绑. 如果资源包含相似的内容，则捆绑的资源可能会提供更好的压缩效果.
Bundled resources may require additional infrastructure at build or delivery time to generate the associated bundle. Bundled resources may provide better compression if the resources contain similar content.
...
HTTP/2通过提供对请求和响应多路复用的支持消除了这种不幸的折衷，这意味着我们现在可以通过提供更多的粒度资源来优化我们的应用程序:每个资源都可以具有优化的缓存策略(过期时间和重新验证令牌) )，并进行单独更新，而不会使捆绑软件中的其他资源无效.简而言之，HTTP/2使我们的应用程序可以更好地利用HTTP缓存.
HTTP/2 removes this unfortunate trade-off by providing support for request and response multiplexing, which means that we can now optimize our applications by delivering more granular resources: each resource can have an optimized caching policy (expiry time and revalidation token) and be individually updated without invalidating other resources in the bundle. In short, HTTP/2 enables our applications to make better use of the HTTP cache.
我不认为重复发生会大大减小文件大小.而且，文件大小只是延迟和预期速度的一方面.例如，即使初始加载速度更快，当用户第二次访问时会发生什么?如果一个文件需要失效怎么办?
I don't think that recurrences will decrease file size very much. Also, the file size is just one aspect of latency and percieved speed. For example, even if the initial load is faster, what happens when the user visits for a second time? What if one file needs to be invalidated?
尽管我没有看到有关您的问题的任何具体数据，但这是Google针对http/1.1与SPDY(http://的前身)的结果:
Although I have not seen any specific data regarding your question, here are results from Google for http/1.1 vs SPDY, a predecessor to http/2:
除非有人进行一些测试以找出答案，否则最终您的问题的答案将是一种意见.
Ultimately the answer to your question will be an opinion, unless someone does some testing to find out.
这篇关于带有缩小功能的单捆vs通过http/2的多个文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
