为什么捆绑优化不再是HTTP/2中的问题

Question

我读了捆绑systemjs文档的部分内容,在HTTP/2中不再需要捆绑优化:

在HTTP/2上,这种方法可能更为可取,因为它允许在浏览器中单独缓存文件,这意味着不再需要对包进行优化.

我的问题:

1. 这意味着我们在使用HTTP/2时不需要考虑捆绑脚本或其他资源？
2. HTTP/2中有什么功能可以启用此功能？

Answer 1

在使用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倍(通常占据页面渲染时间).

鉴于网络内容的趋势要更加丰富,它将拥有更多的资源; 资源越多,HTTP/2相对于HTTP/1.1就越好.

在HTTP/2多路复用之上,您有HTTP/2推送.

如果没有HTTP/2推送,浏览器必须请求主要资源(*.html页面),下载它,解析它,然后安排下载主要资源引用的30个资源.

HTTP/2 Push允许您在请求引用它们的主资源时获取30个资源,再次保存一次往返,这要归功于HTTP/2多路复用.

它实际上是HTTP/2的多路复用功能,可以让您忘记资源捆绑.

您可以查看我在各种会议上提供的HTTP/2会话的幻灯片.

Answer 2

HTTP/2支持"服务器推送",它废弃了资源捆绑.所以,是的,如果您使用HTTP/2,捆绑实际上是一种反模式.

有关详细信息,请查看:https://www.igvita.com/2013/06/12/innovating-with-http-2.0-server-push/

Answer 3

捆绑在现代 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/

这两篇文章都得出了“构建过程将继续存在”的结论。

Answer 4

如果您的网站是

1. 通过 HTTP 提供服务（HTTP 2.0 需要HTTPS）
2. 由不支持ALPN和HTTP 2的服务器托管。
3. 需要支持旧浏览器（敏感和旧系统）
4. 需要支持 HTTP 1 和 2（优雅降级）

有两个 HTTP 2.0 功能使捆绑变得过时：

1. HTTP 2.0多路复用和并发（允许在单个 TCP 连接上请求多个资源）
2. HTTP 2.0服务器推送（服务器推送允许服务器抢先将其认为客户端需要的响应推送到客户端的缓存中）

PS：捆绑并不是唯一会因 HTTP 2.0 功能的兴起而被淘汰的优化技术。图像分割、域分片和资源内联（通过数据 URI 嵌入图像）等功能将受到影响。

HTTP 2.0 如何影响现有的 Web 优化技术