为什么捆绑优化不再是 HTTP/2 中的一个问题
Why bundle optimizations are no longer a concern in HTTP/2
我在 systemjs 文档的捆绑部分中读到 bundling optimizations no longer needed in HTTP/2:
Over HTTP/2 this approach may be preferable as it allows files to be
individually cached in the browser meaning bundle optimizations are no
longer a concern.
我的问题：
- 也就是说我们在使用的时候不需要考虑捆绑脚本或者其他资源的问题HTTP/2?
- HTTP/2 中有什么启用此功能？
HTTP/2 支持 "server push"，它废弃了资源捆绑。所以，是的，如果您使用 HTTP/2，捆绑实际上是一种反模式。
有关更多信息，请查看：https://www.igvita.com/2013/06/12/innovating-with-http-2.0-server-push/
捆绑优化是在使用 HTTP/1.1 时作为 "best practice" 引入的，因为浏览器只能打开有限数量的特定域连接。
一个典型的网页需要下载 30 多种资源才能呈现。
使用 HTTP/1.1，浏览器打开 6 个到服务器的连接，并行请求 6 个资源，等待这些资源下载，然后请求其他 6 个资源，依此类推（或者当然某些资源会比其他资源下载得更快并且该连接可以比其他连接更早地用于另一个请求）。
关键是 HTTP/1.1 你最多只能有 6 个未完成的请求。
要下载 30 个资源，您需要 5 次往返，这会增加页面呈现的大量延迟。
为了加快页面呈现速度，HTTP/1.1 应用程序开发人员不得不减少对单个页面的请求数。
这导致 "best practices" 例如域分片、资源内联、图像精灵、资源捆绑等，但这些实际上只是解决 HTTP/1.1 协议限制的巧妙技巧。
与 HTTP/2 不同，因为 HTTP/2 是多路复用的。
即使没有 HTTP/2 推送，HTTP/2 的多路复用功能也会使所有这些 hack 变得无用，因为现在您可以使用单个 TCP 连接并行请求数百个资源。
使用 HTTP/2，同样的 30 个资源只需要下载 1 次往返，使您在该操作中的性能直接提高 5 倍（这通常占页面呈现时间的大部分）。
鉴于网络内容的趋势是更丰富，它会拥有更多的资源；资源越多，HTTP/2 相对于 HTTP/1.1.
的表现就越好
在 HTTP/2 多路复用之上，您还有 HTTP/2 推送。
没有HTTP/2推送，浏览器要请求主资源（*.html页面），下载，解析，然后安排下载引用的30个资源主要资源。
HTTP/2 推送允许您在请求引用它们的主要资源时获取 30 个资源，再次感谢 HTTP/2 多路复用。
真是HTTP/2的多路复用特性，让你忘记了资源捆绑
大家可以看看我在各种会议上给的HTTP/2session的slides。
如果您的网站是
，捆绑仍然有用
- 在 HTTP 上提供（HTTP 2.0 需要 HTTPS）
- 由不支持 ALPN and HTTP 2 的服务器托管。
- 需要支持旧浏览器（敏感和遗留系统）
- 需要同时支持 HTTP 1 和 2（优雅降级）
有两个 HTTP 2.0 功能使捆绑过时：
- HTTP 2.0 Multiplexing 和并发（允许在单个 TCP 连接上请求多个资源）
- HTTP 2.0 Server Push（服务器推送允许服务器抢先将它认为客户端需要的响应推送到客户端的缓存中）
PS：捆绑并不是唯一会因 HTTP 2.0 功能的兴起而被淘汰的优化技术。 image spriting、domain sharding 和 resource inlining（通过数据 URI 嵌入图像）等功能会受到影响。
捆绑在现代 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/
这两个帖子得出的结论是 "build processes are here to stay"。
我在 systemjs 文档的捆绑部分中读到 bundling optimizations no longer needed in HTTP/2:
Over HTTP/2 this approach may be preferable as it allows files to be individually cached in the browser meaning bundle optimizations are no longer a concern.
我的问题：
- 也就是说我们在使用的时候不需要考虑捆绑脚本或者其他资源的问题HTTP/2?
- HTTP/2 中有什么启用此功能？
HTTP/2 支持 "server push"，它废弃了资源捆绑。所以，是的，如果您使用 HTTP/2，捆绑实际上是一种反模式。
有关更多信息，请查看：https://www.igvita.com/2013/06/12/innovating-with-http-2.0-server-push/
捆绑优化是在使用 HTTP/1.1 时作为 "best practice" 引入的，因为浏览器只能打开有限数量的特定域连接。
一个典型的网页需要下载 30 多种资源才能呈现。 使用 HTTP/1.1，浏览器打开 6 个到服务器的连接，并行请求 6 个资源，等待这些资源下载，然后请求其他 6 个资源，依此类推（或者当然某些资源会比其他资源下载得更快并且该连接可以比其他连接更早地用于另一个请求）。 关键是 HTTP/1.1 你最多只能有 6 个未完成的请求。
要下载 30 个资源，您需要 5 次往返，这会增加页面呈现的大量延迟。
为了加快页面呈现速度，HTTP/1.1 应用程序开发人员不得不减少对单个页面的请求数。 这导致 "best practices" 例如域分片、资源内联、图像精灵、资源捆绑等，但这些实际上只是解决 HTTP/1.1 协议限制的巧妙技巧。
与 HTTP/2 不同，因为 HTTP/2 是多路复用的。 即使没有 HTTP/2 推送，HTTP/2 的多路复用功能也会使所有这些 hack 变得无用，因为现在您可以使用单个 TCP 连接并行请求数百个资源。
使用 HTTP/2，同样的 30 个资源只需要下载 1 次往返，使您在该操作中的性能直接提高 5 倍（这通常占页面呈现时间的大部分）。
鉴于网络内容的趋势是更丰富，它会拥有更多的资源；资源越多，HTTP/2 相对于 HTTP/1.1.
的表现就越好在 HTTP/2 多路复用之上，您还有 HTTP/2 推送。
没有HTTP/2推送，浏览器要请求主资源（*.html页面），下载，解析，然后安排下载引用的30个资源主要资源。
HTTP/2 推送允许您在请求引用它们的主要资源时获取 30 个资源，再次感谢 HTTP/2 多路复用。
真是HTTP/2的多路复用特性，让你忘记了资源捆绑
大家可以看看我在各种会议上给的HTTP/2session的slides。
如果您的网站是
，捆绑仍然有用- 在 HTTP 上提供（HTTP 2.0 需要 HTTPS）
- 由不支持 ALPN and HTTP 2 的服务器托管。
- 需要支持旧浏览器（敏感和遗留系统）
- 需要同时支持 HTTP 1 和 2（优雅降级）
有两个 HTTP 2.0 功能使捆绑过时：
- HTTP 2.0 Multiplexing 和并发（允许在单个 TCP 连接上请求多个资源）
- HTTP 2.0 Server Push（服务器推送允许服务器抢先将它认为客户端需要的响应推送到客户端的缓存中）
PS：捆绑并不是唯一会因 HTTP 2.0 功能的兴起而被淘汰的优化技术。 image spriting、domain sharding 和 resource inlining（通过数据 URI 嵌入图像）等功能会受到影响。
捆绑在现代 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/
这两个帖子得出的结论是 "build processes are here to stay"。