前端性能精进之浏览器（三）——图像 - 咖啡机（K.F.J） - 博客园

　　HTTP Archive 在 2022 年关于多媒体的报告中指出，目前大概有 99.9% 的网站或多或少都会包含点图像。

　　并且高达 70% 的移动页面和 80% 的桌面页面的 LCP 指标会受图像的影响。

　　通过这些数据可知，图像在网页中占据着举足轻重的地位，优化图像，对于网页性能可以达到立竿见影的效果。

　　优化的核心是控制图像的尺寸，提前、延迟或减少图像的请求，以及降低对核心 Web 指标的影响。

　　本文所用的示例代码已上传至 Github。

　　以我目前的公司为例，活动页中图像的请求数占比最高可达 64%。

　　若不做优化处理，那么将直接拉长页面的白屏时间，体验将会及其糟糕。

1）懒加载

　　懒加载就是延迟请求的时机，在触发某个特定条件后，再请求。

　　常用的条件是当图像出现在屏幕内时，触发请求。

　　当页面很长时，并不需要在页面首屏加载时就请求所有图像，而是滚动到图像所在位置后，再将图像显示，如下图所示。

　　目前有 3 种方式来实现懒加载。那么在正式讲解之前，需要先了解一下视口的概念。

　　视口（viewport）就是下图中的灰色部分，也就是文档内容的可视区域，图中用粗线框住的是浏览器的外壳部分（如标签页、书签栏、调试工具等）。

　　先来讲解第 1 种懒加载：传统的 JavaScript 实现，原理就是计算图像顶部到视口顶部的距离，包括页面隐藏部分。

　　若此距离大于等于当前滚动条的位置（即可视区域），那么就可以认为满足条件，需要显示图像。

　　假设滚动条是在body中，那么当前可视区域的范围如下所示。

const viewTop = window.pageYOffset;
const viewBottom = window.innerHeight + viewTop;

　　window.pageYOffset 表示视口上边的距离，如果没有出现垂直方向的滚动条，那么对应属性的值为 0。window.innerHeight 表示视口的高度。

　　而图像到视口顶部的距离可以通过 getBoundingClientRect() 的 DOMRect.top 属性得到，如下所示。

const nodeTop = node.getBoundingClientRect().top + viewTop;

　　完整的代码如下所示， blank.gif 是一张 1*1 的空白占位图，data-src 是真实的图像地址，scroll 是滚动条事件。

<img src="blank.gif" data-src="cover.jpg" width="100%" />
<img src="blank.gif" data-src="cover.jpg" width="100%" />
<img src="blank.gif" data-src="cover.jpg" width="100%" />
<script>
  window.addEventListener('scroll', () => {
    const viewTop = window.pageYOffset;
    const viewBottom = window.innerHeight + viewTop;
    // 查询包含 data-src 自定义属性的 img
    document.querySelectorAll('img[data-src]').forEach(node => {
      const nodeTop = node.getBoundingClientRect().top + viewTop;
      if (nodeTop >= viewTop && nodeTop <= viewBottom) {
        node.src = node.dataset.src;
      }
    });
  });
</script>

　　当前只是为了做演示，兼容性和性能方面并未做深入优化，可以参考市面上成熟的懒加载库，例如 Layzr.js。

　　接下来讲解第 2 种通过 Intersection Observer 实现懒加载。

　　Intersection Observer 提供了一种异步的对目标元素与视口是否相交的检测方法，即检测目标元素是否在可视区域中。

　　示例代码如下，省去了位置计算的逻辑，通过 isIntersecting 属性就能判断元素的可见性。

const observer = new IntersectionObserver((entries, observer) => {
  entries.forEach((entry) => {
    // 不在可视区域内就返回
    if (!entry.isIntersecting) return;
    const img = entry.target;
    img.src = img.dataset.src;
    observer.unobserve(img); // 取消监控
  });
});
document.querySelectorAll("img[data-src]").forEach((node) => {
  observer.observe(node);
});

　　最后讲解第 3 种懒加载方式：img 元素的 loading 属性。该属性会指示浏览器当图像不在可视区域时的加载方式。

　　这种方式相比较前两者，最为简洁，不需要编写额外的脚本，示例代码如下所示。

<img src="cover.jpg" loading="lazy" width="300" height="400"/>

　　2022 年有 91.47% 的浏览器已支持 loading 属性，并且大概有 24% 的网站在使用它，相比去年有 1.4 倍的增长。

　　但是其延迟加载的规则，即图像与视口顶部的距离是多少时开始加载，全部由浏览器自行定义。

　　注意，在 Chrome 中调试发现，页面打开有两三屏的图像就开始请求了，开始滚动后，剩余的图像就开始陆续请求。

　　并不是说到了图像的可视区域后，才开始请求。

2）预加载

　　预加载和懒加载正好相反，它是在图像还没出现在可视区域时提前请求。

　　之前做过一次公司招聘的活动页，其中会涉及到好多动画和很多图像，并且需要在手机中翻页浏览。

　　一开始将所有图像地址直接写在页面中，在测试环境就发现打开非常慢（如下图所示），过了几十秒后才会出现 Loading 过渡动画。

　　于是就对其进行优化，将图像的默认请求替换成一张空白图（与之前的懒加载一样），然后在脚本执行后再将首屏替换成真实地址。

　　示例代码如下，初始化 Image 实例，在触发 load 事件时执行自定义回调，可以是替换 img 元素地址。

function loadImage(url, callback) {
  const img = new Image();
  img.src = url;
  img.onload = function () {
    //将回调函数的 this 替换为Image对象
    callback.call(img);
  };
}
document.querySelectorAll("img[data-src]").forEach((node) => {
  loadImage(node.dataset.src, function () {
    node.src = this.src;
  });
});

　　在翻页时，可以将后面几页的图像进行预加载，然后在翻到那页后，不会出现等待图像加载的情况，并且动画就会更加丝滑和顺畅。

3）Data URI

　　img 元素的 src 属性或 CSS 的 background-image 属性的值都可以是一个经过 Base64 编码后 Data URI，这样能减少额外的HTTP请求。

　　Data URI 由协议、MIME 类型（可选）、Base64 编码设定（可选）和内容组成，格式如下：

data:[<mime type>][;base64],<data>

　　在实际使用中的代码片段如下：

data:image/png;base64,/9j/4AAQSkZJRgAB...

　　Base64 会以每 6 个比特为一个单元，对应某个字符，如果要编码的字节数不能被 3 整除，就用 0 在末尾补足。

　　例如编码 PW，最后得到的值是 UFc=，计算过程如下图所示。

　　虽然使用 Data URI 减少了一次 HTTP 请求，但它会让嵌入的文档体积膨胀四分之三，影响浏览器渲染。

　　并且还会降低 Gzip 的压缩效率，破坏资源的缓存。

　　若要使用，需要权衡利弊，尽量考虑小尺寸和低更新频率的图像。

　　大多数页面至少有一张超过 100 KB 的图像，而在页面尺寸排行中，前 10% 的页面至少有一张接近 1 MB 或更大的图像。

　　因此，压缩或降低图像的大小，可以显著地提升页面性能。

1）压缩

　　图像压缩分为有损和无损。

　　前者会改变图像本身，减少信息量，降低图像质量，文件无法还原，但是压缩效率会比较高。

　　后者会优化数据存储方式，利用算法描述重复信息，文件可以还原，但是压缩效率比有损低。

　　在线压缩网站 TinyPNG 采用智能有损压缩技术对图像进行处理，在我实际使用时，发现最高可压缩 70% 以上的大小。

　　原理就是通过合并图中相似的颜色，将 24 位的 PNG 图像压缩成小得多的 8 位色值的图像，并且去掉了不必要的元数据。

　　经过压缩后的图像，人的肉眼并不会看出与原图明显的差异。

　　若是要用代码对图像进行压缩，可以采用三种触发时机。

　　第一种是在图像上传到服务器后，通过成熟的第三方 Node 库（例如 imagemin、node-ffmpeg 等）进行压缩处理。

　　第二种是在访问图像地址时，带上各类参数，动态的对图像进行压缩或裁剪，例如 cover.png?w/100，按比例裁剪成 100 的宽度。

　　第三种是在构建过程中对图像进行压缩，压缩后再上传到服务器中，例如 webpack 的 ImageMinimizerPlugin 插件等。

　　目前市面上流行的 CDN 服务都应该会提供此类功能。

2）WebP

　　WebP 是由 Google 提供的一种图像格式，支持无损和有损两种压缩。

　　官方资料表明，WebP 比 PNG 格式的图像小 26%，比 JPEG 格式的图像小 25~34% 。

　　在可以接受有损压缩的情况下，有损 WebP 也支持透明度，并且其文件大小通常比 PNG 小 3 倍。

　　虽然表现如此优秀，但是 2022 年，WebP 格式的使用率只占 8.9%，如下图所示，GIF、JPEG 和 PNG 仍然是主流。

　　阻碍其推广的一大问题是兼容性，好在目前 iOS 14 以上已经支持 WebP，不考虑 IE 的话，主流的浏览器都已支持 WebP 格式。

3）响应式

　　响应式是指根据屏幕尺寸、像素密度或其它设备特性，动态的请求最符合场景的图像。

　　像素密度（PPI）就是每英寸像素，计量设备屏幕的精细程度，值越高图像越精细，常见的屏幕有 Retina、XHDPI 等。

　　接下来用一个例子来演示不同尺寸的屏幕显示不同的图像，首先为 img 元素声明 srcset 属性。

　　用逗号分隔多个描述字符串，每一段包含图像地址和宽度或像素密度描述符，注意，此处的宽度是图像的原始宽度。

　　然后再声明 sizes 属性，其值就是媒体查询的条件和图像的显示宽度，最后一条描述可以省略条件，如下所示。

<img srcset="cover-small.jpg 375w, cover.jpg 2449w" 
    sizes="(max-width: 375px) 375px, 800px" 
    src="cover.jpg" />

　　cover-small.jpg 的原始宽度是 375px，cover.jpg 的原始宽度是 2449px。

　　当设备最大宽度是 375 时，将图像宽度设为 375px，在 srcset 中锁定最接近的那张图像的描述。

　　800px 是默认的图像宽度，当无法满足条件时，就采用这个值。

　　如果在做媒体查询时不清楚各类屏幕尺寸的阈值，那么可以参考 Bootstrap 的 Containers。

　　注意，若在 srcset 声明的是像素密度，那么就不需要再额外声明 sizes 属性了。

　　在 2022 年，srcset 属性的使用占比在 34%，size 属性的使用占比在 13%~19%。

　　如果要同时适配特定的屏幕尺寸和像素密度，那么可以通过 picture 元素实现响应式。

　　下面是一个示例，在 source 元素中，media 是媒体查询条件，srcset 的功能和 img 元素中的相同。

<picture>
  <source media="(max-width: 375px)" srcset="cover-small.jpg, cover-2x.jpg 2x" />
  <img src="cover.jpg" />
</picture>

　　当都不符合条件时，就会采用默认的 img 元素。在 2022 年，picture 元素的使用占比是 7.7%。

　　除了响应式图像，picture 元素还可以用来选择不同格式的图像，如下所示。

　　当浏览器支持 WebP 时，就加载这种格式的图像，否则就加载后面的默认图像。

<picture>
  <source type="image/webp" srcset="cover.webp"> 
  <img src="cover.jpg" />
</picture>

三、其他优化

　　除了上述两类比较大的优化之外，还有一些其他的细碎优化，在此节会列举几个。

　　例如对图像一个比较简单而有益的优化是预设宽高，提前占位，就能避免影响 CLS 的计算。

1）延迟解码

　　图像解码是光栅化过程中一个比较耗时的步骤，当图像越大时，解码时间就越长。

　　那么非合成动画（即非 CSS3 动画）就有可能因主线程被阻塞而卡顿。值得一提的是，CSS3 动画运行在合成线程中，所以不会受其影响。

　　HTMLImageElement.decode() 方法可以确保图像解码后，再将图像添加到 DOM 中，如下所示。

const img = new Image();
img.src = "cover.jpg";
img.decode().then(() => {
  document.body.appendChild(img);
});

2）失败处理

　　在图像请求失败时，对页面的交互并不会造成影响，但是图像会裂开，在视觉体验上比较糟糕。

　　为 img 元素注册 error 事件，就能在错误时做纠正处理。

document.querySelector("img").addEventListener("error", function () {
  this.src = "../assets/img/cover-small.jpg";
});

　　不过，若要想知道究竟是什么原因的错误，目前还无法做到。

　　本文对图像的优化进行了系统性的梳理，首先是对请求做优化。

　　为了更科学的对图像进行请求，列出了懒加载、预加载和 Data URI 三种优化方法。

　　然后对尺寸做优化，讲解了压缩细节，WebP 格式的特点，以及响应式处理的妙用。

　　最后再介绍了几个同样也能优化图像的方法，包括占位、延迟解码和失败处理。