现代图片性能优化及体验优化指南 – 懒加载及异步图像解码方案

技术分享 2年前 (2023-03-02) 0 999+

关注

本文是系列第四篇。系列文章：

图片资源，在我们的业务中可谓是占据了非常大头的一环，尤其是其对带宽的消耗是十分巨大的。

对图片的性能优化及体验优化在今天就显得尤为重要。本文，就将从各个方面阐述，在各种新特性满头飞的今天，我们可以如何尽可能的对我们的图片资源，进行性能优化及体验优化。

懒加载/异步图像解码方案

继续下一个章节。本章节，我们来讨论下图片的懒加载与异步图像解码方案。

图片的懒加载

懒加载是一种网页性能优化的常见方式，它能极大的提升用户体验。到今天，现在一张图片超过几 M 已经是常见事了。如果每次进入页面都需要请求页面上的所有的图片资源，会较大的影响用户体验，对用户的带宽也是一种极大的损耗。

所以，图片懒加载的意义即是，当页面未滚动到相应区域，该区域内的图片资源（网络请求）不会被加载。反之，当页面滚动到相应区域，相关图片资源的请求才会被发起。

在过去，我们通常都是使用 JavaScript 方案进行图片的懒加载。而今天，我们在图片的懒加载实现上，有了更多不一样的选择。

JavaScript 方案实现图片的懒加载

首先，回顾一下过往最常见的，使用 JavaScript 方案实现图片的懒加载。

通过 JavaScript 实现的懒加载，主要是两种方式：

监听 onscroll 事件，通过 getBoundingClientRect API 获取元素图片距离视口顶部的距离，配合当前可视区域的位置实现图片的懒加载
通过 HTML5 的 IntersectionObserver API，Intersection Observer（交叉观察器）配合监听元素的 isIntersecting 属性，判断元素是否在可视区内，能够实现比监听 onscroll 性能更佳的图片懒加载方案

但是，JavaScript 方案的一个劣势在于，不管如何，需要引入一定量的 JavaScript 代码，进行一定量的运算。

到今天，其实我们有更多的其他便捷的方式去实现图片的懒加载。

使用 `content-visibility: auto` 实现图片内容的延迟渲染

首先，介绍一个非常有用，但是相对较为冷门的属性 -- content-visibility。

content-visibility：属性控制一个元素是否渲染其内容，它允许用户代理（浏览器）潜在地省略大量布局和渲染工作，直到需要它为止。

利用 content-visibility 的特性，我们可以实现如果该元素当前不在屏幕上，则不会渲染其后代元素。

假设我们有这样一个 DEMO：

<div class="g-wrap">     // 模块 1     <div class="paragraph">         <p>Lorem Start!</p>            <img src="https://s1.ax1x.com/2023/02/20/pSX1xMV.png" alt="" />         <p>Lorem End!</p>       </div>     // 模块 2     <div class="paragraph">         <p>Lorem Start!</p>            <img src="https://s1.ax1x.com/2023/02/20/pSX1xMV.png" alt="" />         <p>Lorem End!</p>       </div>     // ... 连续几十个上述类似的结构 </div>

只需要给需要延迟（实时）渲染的元素，设置简单的 CSS 样式：

.paragraph {     content-visibility: auto; }

我们来看一下，设置了 content-visibility: auto 与没设置的区别。

如果，不添加上述的 content-visibility: auto 代码，页面的滚动条及滚动效果如下：

那么，在添加了 content-visibility: auto 之后，注意观察页面的滚动条及滚动效果：

可以看到滚动条在向下滚动在不断的抽搐，这是由于下面不在可视区域内的内容，一开始是没有被渲染的，在每次滚动的过程中，才逐渐渲染，以此来提升性能。

Codepen Deom -- content-visibility: auto Image Load Demo

`content-visibility: auto` VS 图片懒加载

当然，其实使用 content-visibility: auto 并不能真正意义上实现图片的懒加载。

这是因为，即便当前页面可视区域外的内容未被渲染，但是图片资源的 HTTP/HTTPS 请求，依然会在页面一开始被触发！

因此，这也得到了一个非常重要的结论：

content-visibility: auto 无法直接替代图片懒加载，设置了 content-visibility: auto 的元素在可视区外只是未被渲染，但是其中的静态资源仍旧会在页面初始化的时候被全部加载。因此，它更像是一个虚拟列表的替代方案。

关于 content-visibility 本文限于篇幅，没有完全展开，但是它是一个非常有意思且对渲染性能有帮助的属性，完整的教程，你可以看我的这篇文章 -- 使用 content-visibility 优化渲染性能

使用 `loading=lazy` HTML 属性实现图片懒加载

OK，content-visibility 很不错，但是略有瑕疵。但是，我们还有其他方式。

HTML5 新增了一个 loading 属性。

到今天，除了 IE 系列浏览器，目前都支持通过 loading 属性实现延迟加载。此属性可以添加到 <img> 元素中，也可以添加到 <iframe> 元素中。

属性的值为 loading=lazy 会告诉浏览器，如果图像位于可视区时，则立即加载图像，并在用户滚动到它们附近时获取其他图像。

我们可以像是这样使用它：

<img src="xxx.png" loading="lazy">

这样，便可以非常便捷的实现图片的懒加载，省去了添加繁琐的 JavaScript 代码的过程。

看看 loading=lazy 到今天（2023-02-26）的兼容性，还是非常不错的：

使用 `decoding=async` 实现图片的异步解码

除了 loading=lazy，HTML5 还新增了一个非常有意思的属性增强图片的用户体验。那就是 decoding 属性。

HTMLImageElement 接口的 decoding 属性用于告诉浏览器使用何种方式解析图像数据。

它的可选取值如下：

sync: 同步解码图像，保证与其他内容一起显示。
async: 异步解码图像，加快显示其他内容。
auto: 默认模式，表示不偏好解码模式。由浏览器决定哪种方式更适合用户。

上文其实也提及了，浏览器在进行图片渲染展示的过程中，是需要对图片文件进行解码的，这一个过程快慢与图片格式有关。

而如果我们不希望图片的渲染解码影响页面的其他内容的展示，可以使用 decoding=async 选项，像是这样：

<img src="xxx.png" decoding="async">

这样，浏览器便会异步解码图像，加快显示其他内容。这是图片优化方案中可选的一环。

同样的，我们来看看到今天（2023-02-26），decoding="async" 的兼容性，整体还是非常不错的，作为渐进增强方案使用，是非常好的选择。

实际检验 `loading=lazy` 与 `decoding=async` 效果

OK，下面我们制作一个简单的 DEMO，试一下 loading=lazy 与 decoding=async 的效果。

我们准备一个拥有 339 个图片的 HTML 页面，每个图片文件的 src 大小不一。

<div class="g-container">     <img src="image1.jpeg">     <img src="image2.jpeg">     // ... 339 个 </div>

CSS 的设置也很重要，由于是纯图片页面，如果不给图片设置默认高宽，最页面刷新的一瞬间，<img> 元素的高宽都是 0，会导致所有 <img> 元素都在可视区内，所以，我们需要给 <img> 设置一个默认的高宽：

img {     margin: 8px;     width: 300px;     height: 200px;     object-fit: cover; }

这样，再不添加 loading=lazy 与 decoding=async 的状态下，看看 Network 的表现：

我这里没有模拟弱网环境，网速非常快，可以看到，发送了 339 个图片资源请求，也就是全部的图片资源在页面加载的过程中都请求了，页面 Load 事件完成的时间为 1.28s。

好，我们给所有的图片元素，添加上 loading=lazy 与 decoding=async：

<div class="g-container">     <img src="image1.jpeg" loading="lazy" decoding="async">     <img src="image2.jpeg" loading="lazy" decoding="async">     // ... 339 个 </div>

看看效果：