[译] 利用并行流渐进加载图片

时间 2019-11-08

标签利用并行渐进加载图片繁體版

原文原文链接

原文地址：Parallel streaming of progressive images

原文做者：Andrew Galloni, Kornel Lesiński.

译文出自：掘金翻译计划

本文永久连接：github.com/xitu/gold-m…

译者：twang1727

校对者：suhanyujie

渐进式图片渲染和 HTTP/2 多路复用技术已经问世一段时间，可是如今咱们将二者以新的方式结合从而发挥出更大的力量。利用 Cloudflare 的渐进式流，图片加载能够缩短一半时间，而浏览器能够更快开始渲染页面。javascript

视频：crates.rs/cf-test/com…

创建 HTTP/1.1 链接的服务器对向客户端发送资源的顺序没有决定权；响应做为没法分割的总体，准确的按照浏览器端请求的顺序来发送。HTTP/2 在这方面的改进在于增长了多路复用和优先，使服务器能够决定选择发送什么数据和发送的时间。咱们利用这些新的 HTTP/2 功能，经过优先发送图片数据中最重要的片断，来提高渐进式图片的感知加载速度。前端

这个功能与全部的主流浏览器兼容，而且不须要页面标记作任何更改，很容易使用。参加 Beta 注册，让你的网站也能使用这一功能吧！java

什么是渐进式图片渲染？

普通的图片加载严格按照从上到下的顺序。若是浏览器只收到了图片文件的一半，那么它只会显示图片的上半部分。渐进式图片的内容的排列不是按从上到下的顺序，而是按细节级别从低到高的排序。即便浏览器只收到一部分数据，它也能够显示整张图片，只是清晰度有损失。随着更多数据接收成功，图片会变的更清晰。android

这一功能对 JPEG 格式颇有用，由于显示图片预览只需 10-15% 的数据，而当 50% 的数据加载以后，图片看起来几乎和整个文件都到达时同样清晰了。渐进式 JPEG 图片的数据和普通图片一致，只是以一种更易用的方式排序，因此渐进式渲染并不增长文件的大小。这是能够实现的，由于 JPEG 并不以像素形式存储图片。它用频率系数来表明图像，就像是一系列预约义的样式，以任意顺序混合都能能够从新构建原图想。JPEG 的内部构造十分有趣，你能够从个人 permormance.now() 会议演讲了解更多。ios

最终结果是，图像用了一半的时间就看起来几乎与加载完毕没区别了，并且不花钱。页面视觉效果完整，并且能够更快投入使用。剩下的图像数据会很快到达，并在浏览者注意到任何缺省以前将图像升级成清晰度完整的质量。git

HTTP/2 渐进式流

可是这有个问题。网站会有多于一张图片（有时甚至是几百张图片）。当服务器以原始的方式一张一张传输图片时，渐进式渲染帮不上什么忙，由于总的来说图片还是按顺序加载：github

收到一半图片的全部数据（但没收到剩下一半图片的任何数据）看起来不如收到全部图片的一半数据。web

并且还有另一个问题：当浏览器未知图像大小的时候，它用占位符布局，再在每张图加载的时候重布局。这会让页面在加载过程当中跳动，这样作很唐突，让用户感到分神、厌烦。后端

咱们的渐进式流新功能对这种状况大幅改进：咱们能够一次性并行发送全部图片。这样浏览器能够尽快的获得全部图片的尺寸信息，进而能够无需等待大量数据就绘制全部图片的预览，并且大图片也不会延迟样式、脚本和其余重要资源的加载。浏览器

并行流渐进式加载图片的概念和 HTTP/2 自己同样古老，可是它须要网络服务器底层部件的特殊处理，因此目前为止这一技术还没被大规模应用。

当咱们改进 HTTP/2 优先级时，咱们意识到它也能够被用来改进这一功能。图片文件做为总体时既不是高优先级也不是低优先级。每一个文件优先级不一样，动态调整优先级给予咱们所需的行为：

含有图片大小的图片头优先级极高，由于浏览器须要尽早知道大小来布局页面。图片头很小，并且早于其余数据发送它没有坏处。

展现图片预览所需的最小量图像数据具备中等优先级（咱们得为尽早完成未加载图片预留空间，可是也要为脚本，字体和其余资源留下足够带宽）。

剩下的图像数据是低优先级的。浏览器能够在可有可无的时候接受它来提升图片质量，由于网页已经彻底可用了。
要了解在每一阶段发送的准确数据量，你须要理解图像文件的结构，可是让网络服务器来解析图像响应，而且把基于格式的行为在协议层级上硬编码，看起来就会很怪异。而把这个问题看成优先级的动态改变来处理，咱们就能够优雅的将底层网络编码与图像格式信息分割开来。咱们能够用 Worker 或者是线下的图像处理工具来分析图片，并指导服务器相应的改变 HTTP/2 优先级。

图片并行流的好处在于它不增长任何开销。咱们仍然发送一样的数据，相同量的数据，咱们只是以一种更聪明的方式来发送它。这个技巧利用了现存网络标准，因此在全部浏览器上都兼容。

瀑布图

如下是从 WebPageTest 获得的瀑布图，展现了普通 HTTP/2 响应和渐进式流的比较。两种状况中的文件一致，传输的数据量一致，总的页面加载时间也一致（在测量偏差内）。图中，蓝色片断表示数据正在传输，绿色表示请求等待。

第一张图展现了图片依次加载的典型服务器行为。图看起来整齐，可是实际的页面加载体验并很差——最后一张图直到将近最后才开始加载。

第二张图展现的是图片并行加载。图上蓝色的垂直线表示的是早期的图片头发送，以及以后渐进式渲染的几个阶段。你能够看出全部图片的数据的有用部分都到达的更早。你可能还会注意到有一张图片是一次性发送的，而不是像其余图片同样分批完成的。那是由于在 TCP/IP 链接创建之初咱们还不知道链接的真实速度，咱们只好牺牲一些优先处理的机会来最大化链接速度。

与其余方法相比的指标

有一些其它的技术也用来更快的提供图片预览，好比低质量图片占位（LQIP），可是它们是有一些缺点的。他们为占位符增长了没必要要的数据，并且一般会干扰浏览器的预加载扫描，而且延迟完整图片的加载，由于将预览更替到完整图片依赖于 JavaScript。

咱们的方法不增长请求，也不增长更多数据。页面总加载时间不会延迟。
咱们的方法不须要 JavaScript。它利用了浏览器原生的功能。
咱们的方法不须要改变页面标记，因此全站部署是安全并简单的。

用户体验的改进能够在例如 SpeedIndex，以及视觉上的完成时间等性能指标上表现出来。请注意，普通的图片下载的过程看起来是线性的，可是渐进流使它能够很快的进行到基本完成:

最大限度地利用渐进式渲染

避免让 JavaScript 损坏效果。隐藏图片直至 onload 事件才显示（利用淡入等）的脚本会使渐进式渲染无效。渐进式渲染用传统的 <img> 元素效果最好。

只有 JPEG 能够吗？

咱们的应用是不依赖于格式的，可是渐进流只对某些文件类型有用。好比说，对脚本或样式应用它是不可行的：这些资源只有未渲染或所有渲染两个状态。

优先发送图片头（包括图片大小）对全部格式都适用。

渐进式渲染的益处对 JPEG（全部浏览器都支持）和 JPEG 2000（Safari 支持）是得天独厚的。GIF 和 PNG 有交错模式，可是这些模式和糟糕的压缩相伴生。WebP 根本不支持渐进式渲染。这就形成了这样一种两难：WebP 一般比同等质量的 JPEG 小 20% 到 30%，可是渐进式 JPEG 看起来 加载得快 50%。有些下一代图像格式对渐进式渲染的支持优于 JPEG，比 WebP 压缩更优，可是浏览器还不支持这些格式。同时大家能够经过修改 Cloudflare 面板的 Polish 设置，在节省带宽的 WebP 和可感知性能更好的渐进式 JPEG 之间选择。

试验用的自定义头

咱们也支持自定义 HTTP 头来进行试验，来优化网站的其余资源的流播。好比，你可让咱们的服务器优先发送动画 GIF 的第一帧，而剩余的帧延后。或者你能够在 HTML 文档 <body> 加载前优先加载 <head> 标签里提到的资源。

自定义头只能在 Worker 中设置。句法是用逗号隔开的包括优先级和并发选项的文件位置清单。优先级和并发选项与前一篇博客提到的整文件 cf-priority 头同样。

cf-priority-change: <offset in bytes>:<priority>/<concurrency>, ...
复制代码

好比，对于渐进式 JPEG 咱们用这个（Worker 中的 JavaScript 片断）：

let headers = new Headers(response.headers);
headers.set("cf-priority", "30/0");
headers.set("cf-priority-change", "512:20/1, 15000:10/n");
return new Response(response.body, {headers});
复制代码

它会告诉服务器，当一开始发送最早的 512 字节时用 30 做为优先级。而后切换到优先级 20 以及必定程度的并发（/1），最后当发送文件的 15000 字节以后，切换到低优先级高并发（/n）把文件的剩余部分发送完。

咱们试着分割 HTTP/2 帧来匹配标头中的指定偏移量，从而尽快改变发送的优先级。可是，优先级并不保证不一样流上的数据会被严格按照指示复用，由于服务器只是在多路流同时须要发送数据时才应用优先级排序。若是某些请求从上游浏览器或缓存到达的更早，服务器可能会当即发送它们，而不是等待其余请求。

试一试！

你能够用咱们的 Polish 工具来把你的图片转化成渐进式 JPEG。加入 beta 来优雅地使用并行流。

若是发现译文存在错误或其余须要改进的地方，欢迎到掘金翻译计划对译文进行修改并 PR，也可得到相应奖励积分。文章开头的 本文永久连接 即为本文在 GitHub 上的 MarkDown 连接。

掘金翻译计划是一个翻译优质互联网技术文章的社区，文章来源为掘金上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注掘金翻译计划、官方微博、知乎专栏。