我在 systemjs 文档的捆绑部分中读到，HTTP/2 中不再需要捆绑优化：
通过HTTP/2，这种方法可能更可取，因为它允许文件是 单独缓存在浏览器中，这意味着没有捆绑优化 更长的时间是一个问题。
我的问题：
- 这意味着我们在使用 HTTP/2 时不需要考虑捆绑脚本或其他资源？
- HTTP/2 中有什么功能使此功能启用？
捆绑优化是作为使用 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推送，HTTP/2的多路复用功能也使所有这些黑客都无用，因为现在您可以使用单个TCP连接并行请求数百个资源。
使用 HTTP/2，相同的 30 个资源只需要下载 1 次往返，从而使该操作的性能直接提高 5 倍（这通常主导页面呈现时间）。
鉴于Web内容的趋势是更丰富，它将拥有更多的资源;资源越多，HTTP/2相对于HTTP/1.1的性能就越好。
在HTTP/2多路复用之上，您还有HTTP/2推送。
如果没有 HTTP/2 推送，浏览器必须请求主要资源（*.html 页面），下载它，解析它，然后安排下载主要资源引用的 30 个资源。
HTTP/2推送允许您在请求引用它们的主要资源时获取 30 个资源，从而节省一次往返，这再次归功于 HTTP/2 多路复用。
它实际上是HTTP/2的多路复用功能，它允许您忘记资源捆绑。
你可以看看我在各种会议上给出的HTTP/2会议的幻灯片。
HTTP/2 支持"服务器推送"，这淘汰了资源的捆绑。所以，是的，如果你使用的是HTTP/2，捆绑实际上是一种反模式。
有关更多信息，请查看以下内容：https://www.igvita.com/2013/06/12/innovating-with-http-2.0-server-push/
在现代JavaScript构建中做了很多事情。HTTP/2 仅通过使额外请求的成本比 HTTP/1 便宜得多来解决最小化客户端和服务器之间请求量的优化问题
。但是，今天的捆绑不仅仅是为了最大限度地减少客户端和服务器之间的请求数量。另外两个相关方面是：
- 摇树：像WebPack和Rollup这样的现代捆绑器可以消除未使用的代码（甚至来自第三方库）。 压缩
- ：更大的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/
这两个帖子得出的结论是"构建过程将继续存在"。
如果您的网站是
- 在 HTTP 上提供（HTTP 2.0 需要 HTTPS）
- 由不支持 ALPN 和 HTTP 2 的服务器托管。
- 需要支持旧版浏览器（敏感系统和旧版系统）
- 需要同时支持 HTTP 1 和 2（正常降级）
有两个 HTTP 2.0 功能使捆绑过时：
- HTTP 2.0 多路复用和并发（允许在单个 TCP 连接上请求多个资源）
- HTTP 2.0 服务器推送（服务器推送允许服务器抢先将它认为客户端需要的响应推送到客户端的缓存中）
PS：捆绑并不是唯一的优化技术，它会因HTTP 2.0功能的兴起而消除。图像精灵、域分片和资源内联（通过数据 URI 嵌入图像）等功能将受到影响。
HTTP 2.0如何影响现有的Web优化技术