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 格式的特点,以及响应式处理的妙用。
最后再介绍了几个同样也能优化图像的方法,包括占位、延迟解码和失败处理。