使用 Javascript 延迟加载图像是否保留了 HTTP2 的优势？答案

【问题标题】：Does using Javascript to lazy-load images retain the benefits of HTTP2?使用 Javascript 延迟加载图像是否保留了 HTTP2 的优势？
【发布时间】：2017-02-09 12:07:11
【问题描述】：

我正在使用 HTTP2 加载我网站上的所有图像，并且在一些地方我还使用带有 jQuery 插件的延迟加载，即仅在图像进入视口时加载图像。

我的问题是，使用 Javascript 以这种方式加载图像会否定 HTTP2 的好处吗？不是一次并行加载许多图像，而是一个接一个地加载，或者一次加载几个，这感觉像是回到 HTTP1 的一步。浏览器通过 JS 加载资源时还使用复用吗？

【问题讨论】：

您认为现在使用 JS 延迟加载图像有什么好处？很少有充分的理由这样做。浏览器非常擅长优先处理内容。
延迟加载还是有用的，更多的是和带宽有关，为什么你会认为浏览器在使用javascript时会停止使用多路复用？如果惰性加载器是异步的，我认为没有任何性能损失的原因。
@Brad 我不确定这是不是真的，因为浏览器必须等待下载所有图像才能运行任何跟随它们的 JS。
@Keith 如何判断它是否是异步的？
如果你有一个延迟加载脚本，如果它不是异步的，我会感到非常惊讶，而且现在任何同步的 javascript 通常都不受欢迎。延迟加载脚本可能只是设置图像的 src 属性，因此这将是异步的。

标签： javascript image lazy-loading http2 multiplexing

【解决方案1】：

无论您是通过 HTML 标签（如<img>）还是通过 Javascript（XHR 或 fetch API）加载资源或图像，对于浏览器来说都无关紧要。它仍然会根据服务器的功能而不是根据您用于请求资源的方式来选择协议（HTTP/1.1 或 HTTP/2）。

这也意味着通过 Javascript 加载任何内容时，如果服务器支持，您将使用 HTTP/2 和多路复用。当然，您可以利用 HTTP/2 功能，例如只需创建单个 TCP 连接和标头压缩。但是，如果您的库一次只发出一个请求，它可能无法充分利用 HTTP/2，因为那时只会使用一个 HTTP/2 流。在这种情况下，检查库是否可以配置为一次加载多个并行资源可能是有意义的。

【讨论】：

什么时候tcp连接仍然打开，直到浏览器关闭之前连接仍然打开吗？
没有指定，可以由每个浏览器实现单独决定。我猜他们会让它存活一段时间以适应后续请求和 Javascript，然后关闭它。