我在捆绑部分 systemjs 文档中读到HTTP/2 不再需要捆绑优化：
在 HTTP/2 上，这种方法可能更可取，因为它允许将文件单独缓存在浏览器中，这意味着捆绑优化不再是一个问题。
我的问题：
- 这是否意味着我们在使用 HTTP/2 时不需要考虑捆绑脚本或其他资源？
- HTTP/2 中有什么使此功能启用？
问问题
7376 次
4 回答
65
捆绑优化是在使用 HTTP/1.1 时作为“最佳实践”引入的，因为浏览器只能打开到特定域的有限数量的连接。
一个典型的网页需要下载 30 多个资源才能进行渲染。使用 HTTP/1.1，浏览器打开到服务器的 6 个连接，并行请求 6 个资源，等待下载这些资源，然后请求其他 6 个资源，依此类推（当然，某些资源会比其他资源下载得更快，并且该连接可能比其他请求重用）。关键是使用 HTTP/1.1，您最多只能有 6 个未完成的请求。
要下载 30 个资源，您需要 5 次往返，这给页面渲染增加了很多延迟。
为了使页面渲染更快，对于 HTTP/1.1，应用程序开发人员必须减少单个页面的请求数。这导致了“最佳实践”，例如域分片、资源内联、图像分割、资源捆绑等，但这些实际上只是解决 HTTP/1.1 协议限制的巧妙技巧。
对于 HTTP/2，情况有所不同，因为 HTTP/2 是多路复用的。即使没有 HTTP/2 Push，HTTP/2 的多路复用功能也使所有这些 hack 变得无用，因为现在您可以使用单个 TCP 连接并行请求数百个资源。
使用 HTTP/2，同样的 30 个资源只需要 1 次往返即可下载，使您在该操作中的性能直接提高 5 倍（这通常支配页面渲染时间）。
鉴于网络内容的趋势是更丰富，它会有更多的资源；资源越多，HTTP/2 相对于 HTTP/1.1 的性能就越好。
在 HTTP/2 多路复用之上，您还有 HTTP/2 Push。
如果没有 HTTP/2 Push，浏览器必须请求主资源（*.html 页面），下载它，解析它，然后安排下载主资源引用的 30 个资源。
HTTP/2 Push 允许您在请求引用它们的主要资源时获取 30 个资源，从而节省了一次往返，这再次归功于 HTTP/2 多路复用。
真正让你忘记资源捆绑的正是 HTTP/2 的多路复用特性。
您可以查看我在各种会议上提供的 HTTP/2 会话的幻灯片。
于 2015-06-16T09:53:42.110 回答
12
HTTP/2 支持“服务器推送”，它废弃了资源捆绑。所以，是的，如果您使用的是 HTTP/2，那么捆绑实际上是一种反模式。
有关更多信息，请查看：https ://www.igvita.com/2013/06/12/innovating-with-http-2.0-server-push/
于 2015-06-16T08:06:24.400 回答
12
捆绑在现代 JavaScript 构建中做了很多工作。HTTP/2 仅通过使额外请求的成本比 HTTP/1 便宜得多来解决最小化客户端和服务器之间的请求数量的优化
但是今天的捆绑不仅仅是为了减少客户端和服务器之间的请求数量。另外两个相关方面是：
- Tree Shaking：WebPack 和 Rollup 等现代捆绑程序可以消除未使用的代码（甚至来自 3rd 方库）。
- 压缩：可以更好地压缩更大的 JavaScript 包（gzip、zopfli ...）
HTTP/2 服务器推送也会通过推送浏览器不需要的资源来浪费带宽，因为他仍然将它们放在缓存中。
关于这个主题的两个好帖子是：
- http://engineering.khanacademy.org/posts/js-packaging-http2.htm
- https://www.contentful.com/blog/2017/04/04/es6-modules-support-lands-in-browsers-is-it-time-to-rethink-bundling/
这两篇文章都得出结论，“构建过程将继续存在”。
于 2017-08-26T14:12:52.950 回答
4
如果您的网站是，捆绑仍然有用
有两个 HTTP 2.0 特性使捆绑变得过时：
PS：捆绑并不是唯一一种会因 HTTP 2.0 特性的兴起而被淘汰的优化技术。图像分割、域分片和资源内联（通过数据 URI 嵌入图像）等功能将受到影响。
于 2017-06-26T04:36:01.810 回答