关于前端:现代图片性能优化及体验优化指南

之前，整个《古代图片性能优化及体验优化指南》分了 5 篇来发，本文是系列合集，不便大家珍藏及连贯浏览。

图片资源，在咱们的业务中堪称是占据了十分大头的一环，尤其是其对带宽的耗费是非常微小的。

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

图片类型的选取及 Picture 标签的应用

首先，从图片的类型上而言，除了常见的 PNG-8/PNG-24，JPEG，GIF 之外，咱们更多的关注另外几个较新的图片格式：

• WebP
• JPEG XL
• AVIF

首先，通过一张表格，疾速过一下这几个图片，咱们将从图片类型、通明通道、动画、编解码性能、压缩算法、色彩反对、内存占用、兼容性方面，比照它们：

首先，理解理解上述的一些参数含意：

• Alpha 通道：图片是否反对通明的个性

当然，须要指出的是，Alpha 没有透明度的意思，不代表透明度。opacity 和 transparency 才和透明度无关，前者是不透明度，后者是透明度。比方 css 中的「opacity: 0.5」就是设定元素有 50% 的不透明度。起初 Alvy Ray Smith 提出每个像素再减少一个 Alpha 通道，取值为0到1，用来贮存这个像素是否对图片有「奉献」，0代表通明、1代表不通明。也就是说，「Alpha 通道」贮存一个值，其外在体现是「透明度」，Alpha 和透明度没啥关系

• 动画：很好了解，图片是否反对多帧率动静图片，相似于 GIF
• 编解码性能：图像的解码与编码。这个很要害，很多人看待图片容易漠视图片的编解码性能，解码图像次要从图像文件中读出图像数据，而编码则是将图像数据写入图像文件。解码与编码的过程正好相同。而这两者的性能耗时会影响咱们页面的的展现性能。

• 压缩算法：该图片格式是否反对压缩，反对的话，图片的压缩又会分为无损压缩与有损压缩

  有损压缩算法是一种数据压缩办法，通过此办法压缩、解压的数据会与原始数据不同然而十分靠近。原理是借由将主要的信息数据舍弃，就义一些品质来缩小数据量、进步压缩比

无损压缩指数据通过压缩后，信息不受损失，还能完全恢复到压缩前的原样。无损压缩通常用于严格要求“通过压缩、解压缩的数据必须与原始数据统一”的场合。

• 色彩反对：会分为索引色与间接色，在过来，为了节俭存储空间，并非所有图片都能反对所有色彩值，因而存在索引色这种优化形式。

  索引色彩是一种以无限的形式治理数字图像色彩的技术，以节俭计算机内存和文件存储，同时减速显示刷新和文件传输。即用一个数字来代表（索引）一种色彩，在存储图片的时候，存储一个数字的组合，同时存储数字到图片色彩的映射。这种形式只能存储无限种颜色。索引色常见有1位（即黑白），8位（即灰阶/256色），16位（即高彩），24位（即真彩），30/36/48位（即全彩）。

间接色应用四个数字来代表一种色彩，这四个数字别离代表这个色彩中红色、绿色、蓝色以及透明度（即 RGBA）。当初风行的显示设施能够在这四个维度别离反对256种变动，所以间接色能够示意2的32次方种颜色。

• 内存占用：图片对内存资源的占用
• 兼容性：影响图片格式是否大规模推广的外围因素之一

WebP vs JPEG XL vs AVIF: JPEG 代替之战

因为传统的 PNG-8/PNG-24，JPEG，GIF 各自或多或少都存在一些问题，近些年来它们的代替计划之争也愈演愈烈，外围领跑者可能是 WebP、JPEG XL、AVIF。

再简略理解理解它们：

WebP

WebP 最后由 Google 在 2010 年 9 月公布，其个性总结如下：

1. 能够同时提供无损/有损压缩（像 JPEG 一样）和反对透明度（像 PNG 一样）的图片文件格式
2. 反对动画成果（像 GIF 一样）
3. WebP 次要劣势在于有损编码，其无损编码的性能和压缩比体现个别
4. WebP 的毛病在于其编解码性能不是特地现实
5. 在兼容性方面，除了 IE，根本曾经失去了全系列浏览器反对

对于简单的图像（比方照片）来说，WebP 无损编码体现并不好，但有损编码体现却十分棒。相近品质的图片解码速度 WebP 相距 JPEG 也曾经相差不大了，而文件压缩比却能晋升不少。

下图是我之前还在 TX 的时候做的一个测试比照：

加载同样张数的 JPEG 与 WebP 的耗时比照：

对于 WebP 图片格式，简略做个总结：

1. 目前 WebP 与 JPEG 相比拟，据材料考据，编码速度慢 10 倍，解码速度慢 1.5 倍
2. WebP 尽管会减少额定的解码工夫，但因为大幅缩小了文件体积，缩短了加载的工夫，大页面图片量较多的场景下，页面的渲染速度是有较大放慢的
3. 目前而言，是 WebP、JPEG XL、AVIF 三者中兼容性最好的

截止至（2023-02-05）的兼容性图：

JPEG XL

JPEG XL 由联结图像专家组（开发原始 JPEG 规范的同一组织）于 2021 年公布，旨在成为传统 JPEG 的长期替代品。作为一种免版税的开源规范，JPEG XL 的创建者心愿其格局的开放性可能吸引网络开发人员采纳该规范，该格局的扩大名为 .jxl，JXL 外围比特流于 2021 年 1 月解冻，文件格式于 2021 年 4 月定稿。：

JPEG XL 中的 X 指 2000 年以来的多个 JPEG 规范的名称：JPEG XT、JPEG XR、JPEG XS，而 L 示意 ‘long-term’，示意“长期”。创立这种格局是为替换旧的JPEG文件格式，并应用足够长的工夫。

其次要特点有：

• 与传统图像格式（例如JPEG、GIF和PNG）相比，有着更佳的效率与更丰盛的性能
• 全面反对广色域和 HDR，反对 Alpha 通道，反对多帧（也就是动画反对）
• 有损压缩时：雷同的视觉品质，比 JPEG 小约 60％。
• 无损压缩时：比 PNG 减小约 35％（对于 HDR，减小 50％）。
• 反对无损 JPEG 转码，减小约 20％ 文件大小。
• 渐进式解码，专为反对不同显示分辨率的响应式加载
• 开源收费：具备应用三条款版BSD许可证的开源参考实现的免版税格局

看看同一张图片，雷同品质下的大小体现：

数据起源：技术周刊 2021-04-15：2021最值得期待的新技术 JPEG XL

JPEG XL 是目前而言，最有可能全面代替传统图片格式（Gif、PNG、JPEG）的下一代规范，当然，在明天，须要看看其兼容性：

好吧，目前的兼容有点离谱。Chrome 从 91 版本开始曾经实验室性质反对了 .jxl 格局的图片，须要通过 --enable-features=JXL 配置开启，遗憾的是，从 Chrome 110 开始，Chrome 又不再反对 JPEG XL 。

乏味的是，Chrome 从 110 版本开始中弃用了对 JPEG-XL 的反对，谷歌的答复是，人们对 JPEG-XL 没有足够的趣味，并且与现有格局相比也没有足够的劣势。谷歌之前始终对 JPEG 的反对都是实验性的性质的，他们认为 JPEG XL 不足生态系统反对，并且该格局没有足够多的益处（绝对 WebP 和 AVIF）。也就是说，目前而言，Chrome 对 WebP 和 AVIF 等代替格局更感兴趣。

AVIF

最初，咱们再来看看 AVIF 格局图片。

AVIF 是由凋谢媒体联盟 (AOM) 开发并于 2019 年公布的另一种最新图像格式。该格局基于 AV1 视频编解码器，源自视频帧。其特点如下：

• 同样的，与传统图像格式（例如JPEG、GIF和PNG）相比，有着更佳的效率与更丰盛的性能
• 反对 Alpha 通道，反对动静图像和动画
• 反对有损、无损压缩。AVIF 文件在低保真有损图像压缩方面表现出色（比 JPEG XL 更优）。压缩的 AVIF 图像保留了很高的图片品质，防止了宜人的压缩伪影等问题
• 相对而言，AVIF 的解码和编码速度不如 JPEG XL，它不反对渐进式渲染
• 最初，再看看兼容性，目前（2023-02-05）它的兼容性介于 WebP 与 JPEG XL 之间

看看 CaniUse 的数据：

下图是 WebP vs JPEG XL vs AVIF 三者在图片解码上的性能体现：

图片来源于：Encode.su — JPEG XL vs. AVIF

从图中能够看到，对于解码性能的比照，后果竟然是 WebP > AVIF > JPEG XL 。JPEG XL 的编解码性能并没有其形容的那么弱小。

图片格式总结

总结一下，WebP、AVIF 和 JPEG XL 都是浏览器不广泛支持的新型图像格式。尽管 WebP、AVIF 曾经存在很长时间，但到明天，影响它们大规模应用的仍旧是兼容问题。它们各自有各自的特点与劣势，谁能胜出仍未通晓。

尽管 AVIF、JPEG XL 等新型图片格式未失去任何浏览器的齐全反对，然而在新版本的 Chrome、Firefox 和 Edge Chromium，能够应用配置标记启用对应图像格式，配合 HTML 的 Picture 标签，咱们还是能够肯定水平上对咱们的图片进行格局抉择上的优化的。

这，就能够引出咱们要说的第二局部 — HTML Picture 标签的应用。

Picture 元素的应用

HTML5 标准新增了 Picture Element。那么 <picture> 元素的作用是什么呢？

<picture> 元素通过蕴含零或多个 <source> 元素和一个 <img> 元素来为不同的显示/设施场景提供图像版本。浏览器会抉择最匹配的子 <source> 元素，如果没有匹配的，就抉择 <img> 元素的 src 属性中的 URL。而后，所选图像出现在 <img> 元素占据的空间中。

什么意思呢？怎么应用 <picture> 元素呢？

假如，没有 <picture> ，只有 <img> 元素，咱们想尽可能在反对一些古代图片格式的浏览器上应用相似于上述咱们提到的 WebP、AVIF 和 JPEG XL 等图片格式，而不反对的浏览器回退应用惯例的 JPEG、PNG 等。没错，就是一种渐进加强的思维，该怎么办呢？

只能是 JavaScript 去写对应的逻辑，通过 JS 脚本进行个性查问，动静赋值给 <img> 的 src。

而有了 <picture> 后，浏览器将原生反对上述的一些列操作，咱们来看看对应的语法：

<picture>
  <!-- 可能是一些对兼容性有要求的，然而性能体现更好的古代图片格式-->
  <source src="image.avif" type="image/avif">
  <source src="image.jxl" type="image/jxl">
  <source src="image.webp" type="image/webp">

   <!-- 最终的兜底计划-->
  <img src="image.jpg" type="image/jpeg">
</picture> 

上述代码的含意是：

• 第 1 个 source 元素指向新 AVIF 格局的图像。如果浏览器反对 AVIF 图像，那么它会抉择该图像文件。否则，它将挪动到下一个 source 元素。
• 第 2个 source 元素指向新 JPEG XL 格局的图像。如果浏览器反对 JPEG XL 图像，那么它会抉择该图像文件。否则，它将挪动到下一个 source 元素。
• 第 3 个 source 元素指向一张WebP 格局的图像。如果浏览器可能渲染 WebP 图像，它将应用该图像文件。
• 否则浏览器将回退到应用 img 元素 src 属性中的图像文件。img 元素指向的是 JPEG 格局的图片，它是最终的兜底计划。

这意味着当初咱们能够在不就义向后兼容性的状况下开始应用新的图像格式。

简而言之，<picture> 元素的作用：

1. 通过 <source> 给出一系列对兼容性有所要求的古代图片格式选项
2. 通过 <img> 给出兜底的高兼容性图片格式选项
3. 浏览器通过对给出的图片格式做个性检测，要决定加载哪个 URL，user agent 查看每个 <source> 的 srcset、media 和 type 属性，来抉择最匹配页面以后布局、显示设施特色等的兼容图像。
4. 最终，所选图像出现在 <img> 元素占据的空间中

模块总结

总结一下，本文对常见的图片格式以及最新的几种未被大规模兼容的图片格式进行的比照，它们别离是：

• PNG-8/PNG-24
• JPEG
• GIF
• WebP
• JPEG XL
• AVIF

其后，着重介绍了 3 种古代图片格式：WebP、JPEG XL、AVIF。绝对于 JPEG 等传统格局，它们在色调体现、动画反对、是否反对无损有损压缩、压损比率、编解码性能上有着更进一步的晋升，正在成为下一阶段 Web 图像的规范。

最初，介绍了 <picture> 元素，借助它，咱们能更好的实现图片的渐进加强。

适配不同的屏幕尺寸及 DPR

下一个模块，咱们来看看图片资源如何更好的适配不同的屏幕尺寸。

这里首先会波及一个准备常识，屏幕的 DPR 值，那么，什么是 DPR 呢？要理解 DPR，又须要晓得什么是设施独立像素 以及 物理像素。

设施独立像素

以 iPhone6/7/8为例，这里咱们关上 Chrome 开发者工具：

这里的 375 * 667 示意的是什么呢，示意的是设施独立像素（DIP），也能够了解为 CSS 像素，也称为逻辑像素：

设施独立像素 = CSS 像素 = 逻辑像素

如何记忆呢？这里应用 CSS 像素来记忆，也就是说。咱们设定一个宽度为 375px 的 div，刚好能够充斥这个设施的一行，配合高度 667px ，则 div 的大小刚好能够充斥整个屏幕。

物理像素

OK，那么，什么又是物理像素呢。咱们到电商网站购买手机，都会看一看手机的参数，以 JD 上的 iPhone7 为例：

能够看到，iPhone7 的分辨率是 1334 x 750，这里形容的就是屏幕理论的物理像素。

物理像素，又称为设施像素。显示屏是由一个个物理像素点组成的，1334 x 750 示意手机别离在垂直和程度上所具备的像素点数。通过管制每个像素点的色彩，就能够使屏幕显示出不同的图像，屏幕从工厂进去那天起，它下面的物理像素点就固定不变了，单位为pt。

设施像素 = 物理像素

DPR（Device Pixel Ratio） 设施像素比

OK，有了下面两个概念，就能够牵强附会引出下一个概念。DPR（Device Pixel Ratio） 设施像素比，这个与咱们通常说的视网膜屏（多倍屏，Retina屏）无关。

设施像素比形容的是未缩放状态下，物理像素和设施独立像素的初始比例关系。

简略的计算公式：

DPR = 物理像素 / 设施独立像素

咱们套用一下下面 iPhone7 的数据（取设施的物理像素宽度与设施独立像素宽度进行计算）：

iPhone7’s DPR = iPhone7’s 物理像素宽度 / iPhone7’s 设施独立像素宽度 = 2

750 / 375 = 2
或者是 1334 / 667 = 2

能够失去 iPhone7 的 dpr 为 2。也就是咱们常说的视网膜屏幕。

视网膜（Retina）屏幕是苹果公司”创造”的一个营销术语。 苹果公司将 dpr > 1 的屏幕称为视网膜屏幕。

在视网膜屏幕中，以 dpr = 2 为例，把 4(2×2) 个像素当 1 个像素应用，这样让屏幕看起来更粗劣，然而元素的大小自身却不会扭转：

OK，咱们再来看看 iPhone XS Max：

它的物理像素如上图是 2688 x 1242，

它的 CSS 像素是 896 x 414，很容易得出 iPhone XS Max 的 dpr 为 3。

为不同 DPR 屏幕，提供失当的图片

那么，DPR 和图片适配有什么关系呢？

举个例子，同样的 CSS 像素大小下，屏幕如果有不同 DPR，同样大小的图片渲染进去的成果不尽相同。

咱们以 dpr = 3 的手机为例子，在 300 x 389 CSS 像素大小的范畴内，渲染 1倍/2倍/3倍 图的成果如下：

理论图片所占的物理像素为 900 x 1167。

能够看到，在高 DPR 设施下提供只有 CSS 像素大小的图片，是十分含糊的。

因而，为了在不同的 DPR 屏幕下，让图片看起来都不失真，咱们须要为不同 DPR 的图片，提供不同大小的图片。

那么，有哪些可行的解决方案呢？

计划一：无脑多倍图

假如，在挪动端假如咱们须要一张 CSS 像素为 300 x 200 的图像，思考到当初曾经有了 dpr = 3 的设施，那么要保障图片在 dpr = 3 的设施下也失常高清展现，咱们最大可能须要一张 900 x 600 的原图。

这样，不论设施的 dpr 是否为 3，咱们对立都应用 3 倍图。这样即便在 dpr = 1，dpr = 2 的设施上，也能十分好的展现图片。

当然这样并不可取，会造成大量带宽的节约。

古代浏览器，提供了更好的形式，让咱们可能依据设施 dpr 的不同，提供不同尺寸的图片。

计划二：媒体查问

计划二，咱们能够思考应用媒体查问。到明天，咱们能够通过相应的媒体查问，得悉以后的设施的 DPR 值，这样，咱们就能够在对应的媒体查问中，应用对应的图片。

像是这样：

#id { 
    background: url(xxx@2x.png) 
}
@media (device-pixel-ratio: 2) {
    #id { 
        background: url(xxx@2x.png) 
    }
}
@media (device-pixel-ratio: 3) {
    #id { 
        background: url(xxx@3x.png) 
    }
}

这个计划的毛病在于：

1. 要写的代码可能太多了，而且，可能存在一些介于 1~2，2~3 之间的 DPR 值，不好穷举出所有场景
2. 须要留神语法须要的兼容性，须要增加前缀，譬如 -webkit-min-device-pixel-ratio，当然这个能够由 autoprefixer 辅助解决

计划三：CSS 配合 image-set 语法

image-set 属于 CSS background 中的一种语法，image-set() 函数为设施提供最合适的图像分辨率，它提供一组图像选项，每个选项都有一个相干的 DPR 申明，浏览器将从中抉择最适宜设施的图像进行设置。

什么意思呢，来看看代码：

.img {
    /* 不反对 image-set 的浏览器*/
    background-image: url('../photo@2x.png');

    /* 反对 image-set 的浏览器*/
    background-image: image-set(
        url('./photo@2x.png') 2x,
        url('./photo@3x.png') 3x
    );
}

这样一看，作用应该很清晰了。对于反对 image-set 语法的浏览器：

1. 如果其设施对应的 DPR 为 2，会选取这条 url('./photo@2x.png') 2x 记录，也就是最终失效的 URL 是 './photo@2x.png'；
2. 如果其设施对应的 DPR 为 3，会选取这条 url('./photo@3x.png') 3x 记录，也就是最终失效的 URL 是 './photo@3x.png'；

其中的 2x，3x 就是用于匹配 DRP的。

应用 image-set 的一些痛点与媒体查问计划相似。代码量与兼容性语法，而且难以匹配所有状况。

计划四：srcset 配合 1x 2x 像素密度描述符

简略来说，srcset 能够依据不同的 dpr 拉取对应尺寸的图片：

<div class='illustration'>
   <img src='illustration-small.png'
       srcset='images/illustration-small.png 1x,
               images/illustration-big.png 2x'
   >
</div>

下面 srcset 里的 1x，2x 示意 像素密度描述符，示意

• 当屏幕的 dpr = 1 时，应用 images/illustration-small.png 这张图
• 当屏幕的 dpr = 2 时，应用 images/illustration-big.png 这张图
• 如果不反对 srcset 语法，src='illustration-small.png' 将会是最终的兜底计划

计划五：srcset 属性配合 sizes 属性 w 宽度描述符

下面 1x，2x 的写法比拟容易接受易于了解。

然而，上述 3 种计划都存在对立的问题，只思考了 DPR，然而疏忽了响应性布局的复杂性与屏幕的多样性。

因而，标准还推出了一种计划 — srcset 属性配合 sizes 属性 w 宽度描述符。

srcset 属性还有一个 w 宽度描述符，配合 sizes 属性一起应用，能够笼罩更多的面。

sizes 属性怎么了解呢？它定义图像元素在不同的视口宽度时，可能的大小值。

以上面这段代码为例子：

<img 
        sizes = “(min-width: 600px) 600px, 300px" 
        src = "photo.png" 
        srcset = “photo@1x.png 300w,
                       photo@2x.png 600w,
                       photo@3x.png 1200w,
>

解析一下：

sizes = “(min-width: 600px) 600px, 300px" 的意思是：

1. 如果屏幕以后的 CSS 像素宽度大于或者等于 600px，则图片的 CSS 宽度为 600px
2. 反之，则图片的 CSS 宽度为 300px

也就是 sizes 属性申明了在不同宽度下图片的 CSS 宽度体现。这里能够了解为，大屏幕下图片宽度为 600px，小屏幕下图片宽度为 300px。

须要留神的是，这里大屏、小屏下图片具体的宽度体现，还是须要借助媒体查问代码，经由 CSS 实现的

srcset = “photo@1x.png 300w, photo@2x.png 600w, photo@3x.png 1200w 外面的 300w，600w，900w 叫宽度描述符。

那么，怎么确定以后场景会选取哪张图片呢？

以后屏幕 dpr = 2 ，CSS 宽度为 375px。

以后屏幕 CSS 宽度为 375px，则图片 CSS 宽度为 300px。别离用上述 3 个宽度描述符的数值除以 300。

1. 300 / 300 = 1
2. 600 / 300 = 2
3. 1200 / 300 = 4

下面计算失去的 1、 2、 4 即是算出的无效的像素密度，换算成和 x 描述符等价的值 。这里 600w 算出的 2 即满足 dpr = 2 的状况，抉择此张图。

以后屏幕 dpr = 3 ，CSS 宽度为 414px。

以后屏幕 CSS 宽度为 414px，则图片 CSS 宽度仍为 300px。再计算一次：

1. 300 / 300 = 1
2. 600 / 300 = 2
3. 1200 / 300 = 4

因为 dpr = 3，2 曾经不满足了，则此时会抉择 1200w 这张图。

以后屏幕 dpr = 1 ，CSS 宽度为 1920px。

以后屏幕 CSS 宽度为 1920px，则图片 CSS 宽度变为了 600px。再计算一次：

1. 300 / 600 = .5
2. 600 / 600 = 1
3. 1200 / 600 = 2

因为 dpr = 1，所以此时会抉择 600w 对应的图片。

具体的能够试下这个 Demo：CodePen Demo — srcset属性配合w宽度描述符配合sizes属性

此计划的意义在于思考到了响应性布局的复杂性与屏幕的多样性，利用上述规定，能够一次适配 PC 端大屏幕和挪动端高清屏，一箭多雕。

嗯，总结一下，在实现响应式图像时，咱们同时应用 srcset 和 sizes 属性。它们的作用是：

• srcset：定义多个不同宽度的图像源，让浏览器在 HTML 解析期间抉择最合适的图像源
• sizes：定义图像元素在不同的视口宽度时，可能的大小值

有了这些属性后，浏览器就会依据 srcset/size 来创立一个分辨率切换器的响应式图片，能够在不同的分辨率的状况下，提供雷同尺寸的图像，或者在不同的视图大小的状况下，提供不同尺寸大小的图像。

模块总结

本章节一共列举了 5 种实现响应式图片，适配不同屏幕大小，不同 DPR 的形式，它们别离是：

1. 无脑多倍图的形式
2. DRP 媒体查问
3. CSS Background 中的应用 image-set
4. srcset 配合 1x 2x 像素密度描述符
5. srcset 属性配合 sizes 属性 w 宽度描述符

正当应用它们，能够无效的为不同屏幕，提供最为失当的图片资源，在保障用户体验的同时，尽可能节俭带宽。

它们各有优缺点，能够依据本人理论的业务场景，选取适合绝对老本最低的计划，并且适当的配合 Autoprefixer 以及一些 PostCSS 等工具，简化代码量。

图片的宽高比、裁剪与缩放

OK，上面进入到咱们的第三个模块，图片的宽高比、裁剪与缩放。咱们会介绍 4 个新的个性：

• aspect-ratio
• object-fit
• object-position
• image-rendering

应用 aspect-ratio 防止布局偏移

很多时候，只能应用固定尺寸大小的图片，咱们的布局可能是这样：

对应的布局：

<ul class="g-container">
    <li>
        <img src="http://placehold.it/150x100">
        <p>图片形容</p>
    </li>
</ul>

ul li img {
    width: 150px;
}

当然，万一假如后端接口呈现一张非正常大小的图片，上述不加爱护的布局就会出问题：

所以对于图片，咱们总是倡议同时写上高和宽，防止因为图片尺寸谬误带来的布局问题：

ul li img {
    width: 150px;
    height: 100px;
}

同时，给 <img> 标签同时写上高宽，能够在图片未加载之前提前占住地位，防止图片从未加载状态到渲染实现状态高宽变动引起的重排问题。

当然，到明天，咱们还能够应用 aspect-ratio 设定图片的高宽比。

aspect-ratio CSS 属性为容器规定了一个期待的宽高比，这个宽高比能够用来计算主动尺寸以及为其余布局函数服务。

像是下面的代码，咱们就能够替换成：

ul li img {
    width: 150px;
    aspect-ratio: 3 / 2;
}

当然，有的时候，咱们的布局是响应式动静在变动的，容器的宽度也是不确定的，因而，有了 aspect-ratio 之后，咱们的写法就能够更佳的难受。

ul li img {
    width: 100%;
    aspect-ratio: 3 / 2;
}

这里，容器基于 Flex 弹性布局或者响应式布局，其宽度是不固定的，然而图片的宽高比是固定的，应用 aspect-ratio: 3 / 2 就能十分好的适配这种状况。

咱们借助了 aspect-ratio 这个 CSS 中较新的属性来始终主动取得正确的宽高比，无论其父元素的宽度如何变动。

当然，aspect-ratio 不仅仅只是能使用在这里，在 aspect-ratio 呈现之前，咱们只能通过一些其它的 Hack 形式，譬如设置 padding-top 等形式模仿固定的宽高比。在 aspect-ratio 之后，咱们终于有了设定容器固定宽高比的能力。

object-fit 防止图片拉伸

当然，限度高宽也会呈现问题，譬如图片被拉伸了，十分的难看：

这个时候，咱们能够借助 object-fit，它可能指定可替换元素的内容（也就是图片）该如何适应它的父容器的高宽。

ul li img {
    width: 150px;
    aspect-ratio: 3 / 2;
    object-fit: cover;
}

利用 object-fit: cover，使图片内容在放弃其宽高比的同时填充元素的整个内容框。

object-fit 的取值有 fill、none、contain、cover，与 background-size 相似，能够类比记忆。

也能够看看这张图，很易于了解：

object-fit 还有一个配套属性 object-position，它能够管制图片在其内容框中的地位。（相似于 background-position），默认是 object-position: 50% 50%，如果你不心愿图片居中展现，能够应用它去扭转图片理论展现的 position。

ul li img {
    width: 150px;
    aspect-ratio: 3 / 2;
    object-fit: cover;
    object-position: 50% 100%;
}

像是这样，object-position: 100% 50% 指明从底部开始展现图片。这里有一个很好的 Demo 能够帮忙你了解 object-position。

CodePen Demo — Object position

应用 image-rendering 设置图片缩放算法

绝对于下面几个新个性，image-rendering 会更为冷门。

很多时候，咱们设置一个图片在页面上的展现大小为 200px x 200px，然而图片的原始尺寸可能是 800px x 800px，也可能是 50px x 50px。

这个时候，咱们就能够利用 image-rendering，设置图片在缩放状态下的展现算法。

image-rendering 在特定的场景下，可能起到奇效。

来看这样一个有意思的 DEMO，假如咱们有这样一个原图成果，它是一个二维码，大小为 100px x 100px：

如果咱们将它放大，放到很大，显著，这个二维码会失真，像是这样：

OK，在这种放大失真的状况想，能够应用 image-rendering 扭转图片缩放算法，这里咱们试一下 image-rendering: pixelated：

.img {
  image-rendering: pixelated;
}

成果变动，如下图所示：

能够看到，image-rendering: pixelated 解决过的图像，居然变得如此清晰！

CodePen Demo — QrCode Image-rendering demo

来看看 image-rendering 的几个取值：

• image-rendering: auto：自 Gecko 1.9（Firefox 3.0）起，Gecko 应用双线性（bilinear）算法进行从新采样（高质量）。
• image-rendering: smooth：应用能最大化图像主观观感的算法来缩放图像
• image-rendering: high-quality：与 smooth 雷同，但更偏向于高质量的缩放。
• image-rendering: crisp-edges：必须应用可无效保留对比度和图像中的边缘的算法来对图像进行缩放，并且，该算法既不会平滑色彩，又不会在处理过程中为图像引入含糊。适合的算法包含最近街坊（nearest-neighbor）算法和其余非平滑缩放算法，比方 2×SaI 和 hqx-* 系列算法。此属性值实用于像素艺术作品，例如一些网页游戏中的图像。
• image-rendering: pixelated：放大图像时，应用最近街坊算法，因而，图像看着像是由大块像素组成的。放大图像时，算法与 auto 雷同。

尽管标准定义了挺多值，然而实际上，古代浏览器根本临时只反对：auto、pixelated、以及 -webkit-optimize-contrast（Chrome 下的 smooth）。

看形容都会挺懵逼的，理论应用的时候，最好每个都试一下验证一下成果。总结而言，image-rendering 的作用是在图像缩放时，提供不一样的渲染形式，让图片的展现状态更为多样化，或者说是尽可能的去缩小图片的失真带来的信息损耗。

咱们再看一个 DEMO，原图如下（例子来源于 W3C 标准文档）：

实际效果：

当然，看上去 pixelated 的成果挺好，这是因为这是一张偏差于矢量的图片，细节不多，对于高精度的人物图，就不太实用于 pixelated，容易把图片马赛克化。

真正标准心愿的在放大后让图片尽可能不失真的 crisp-edges 成果，目前临时没有失去浏览器的实现。前面能够期待一下。

CodePen Demo — Image-rendering demo

模块总结

这一章，咱们介绍了 4 个较新的 CSS 个性：

• aspect-ratio：管制容器的宽高比，防止产生布局偏移及抖动
• object-fit：设定内容应该如何适应到其应用高度和宽度确定的框，防止图片拉伸
• object-position：基于 object-fit，设置图片理论展现的 position 范畴
• image-rendering：管制图片在缩放状态下的展现算法

正当利用它们，能够给用户在图片上以更好的体验。

懒加载/异步图像解码计划

持续下一个章节。本章节，咱们来探讨下图片的懒加载与异步图像解码计划。

图片的懒加载

懒加载是一种网页性能优化的常见形式，它能极大的晋升用户体验。到明天，当初一张图片超过几 M 曾经是常见事了。如果每次进入页面都须要申请页面上的所有的图片资源，会较大的影响用户体验，对用户的带宽也是一种极大的损耗。

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

在过来，咱们通常都是应用 JavaScript 计划进行图片的懒加载。而明天，咱们在图片的懒加载实现上，有了更多不一样的抉择。

JavaScript 计划实现图片的懒加载

首先，回顾一下过往最常见的，应用 JavaScript 计划实现图片的懒加载。

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

1. 监听 onscroll 事件，通过 getBoundingClientRect API 获取元素图片间隔视口顶部的间隔，配合以后可视区域的地位实现图片的懒加载
2. 通过 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>

看看成果：

能够看到，这一次只发送了 17 个图片资源申请，页面 Load 事件实现的工夫为 26ms。

1.28s 到 26ms，成果是非常明显的，如果是弱网环境，对首屏加载性能的晋升，会更为显著！

当然，理论我测试的过程也，也独自试过 decoding="async" 的作用，只是因为是纯图片页面，成果不那么显著。感兴趣的同学，能够自行尝试。

模块总结

在本章节中，咱们介绍了不同的形式实现图片的懒加载、提早渲染、异步解码，它们别离是：

1. 通过 onscroll 事件与 getBoundingClientRect API 实现图片的懒加载计划
2. 通过 Intersection Observer（穿插观察器）实现比监听 onscroll 性能更佳的图片懒加载计划
3. 通过 content-visibility: auto 实现图片资源的提早渲染
4. 通过 loading=lazy HTML 属性实现图片懒加载
5. 通过 decoding=async HTML 属性实现图片的异步解码

图片资源的容错及可拜访性解决

OK，最初一个章节，咱们简略聊一聊图片资源的容错及可拜访性解决。

图片的可拜访性解决

可拜访性（A11Y），在咱们的网站中，属于十分重要的一环，然而大部分同学都容易漠视它。

在一些重交互、重逻辑的网站中，咱们须要思考用户的应用习惯、应用场景，从高可拜访性的角度思考，譬如假如用户没有鼠标，仅仅应用键盘，是否顺畅的应用咱们的网站？

十分重要的一点是，进步可拜访性也能让普通用户更容易了解 Web 内容。

基于 Usability & Web Accessibility – image

对于图像信息，咱们须要大抵遵循如下可拜访性准则：

• 所有有意义的 img 元素必须有 alt 属性
• 提供代替 alt 属性的其余形式
• 应用辅助技术暗藏装璜图像

第一点十分好了解，所有的有意义的图片元素都必须要提供 alt 属性。

第二点比拟有意思，在 A11Y 中，其实有一套 WAI-ARIA 规范。WAI-ARIA 是一个为残疾人士等提供无障碍拜访动静、可交互Web内容的技术规范。

简略来说，它提供了一些属性，加强标签的语义及行为：

• 能够应用 tabindex 属性管制元素是否能够聚焦，以及它是否/在何处参加程序键盘导航
• 能够应用 role 属性，来标识元素的语义及作用，譬如应用 <div id="saveChanges" tabindex="0" role="button">Save</div>来模仿一个按钮
• 还有大量的 aria-* 属性，示意元素的属性或状态，帮忙咱们进一步地辨认以及实现元素的语义化，优化无障碍体验

上述第二点，提供代替 alt 属性的其余形式 的含意就是应用 WAR-ARIA 标准提供的诸如 aria-label 和 aria-labelledby 属性为图像提供可拜访的名称。

当存在这些属性时，辅助技术（屏幕阅读器）将疏忽图像的 alt 属性并读取 ARIA 标签。

而第三点，应用辅助技术暗藏装璜图像，又是什么意思呢？

下面第一点 所有有意义的 img 元素必须有 alt 属性，反过来说，页面上也会存在无意义的装饰性的图片，这些图片内容对辅助技术（屏幕阅读器）而言，其实是能够疏忽的。

对于没有任何性能或信息内容的装璜图像，能够通过多种形式对屏幕阅读器暗藏：

• 应用空的 alt 属性
• 应用 ARIA 属性 role="presentation" 表明图片元素是装璜可疏忽图片
• 应用 CSS background 的形式出现这些图片

alt 不要与 title 混同

OK，上面来讲一些有意思的细节内容。

有一个十分根底的常识，简略过一下，也就是图片元素中，alt 与 title 的差别：

• 图片中的 alt 属性是在图片不能失常显示时呈现的文本提醒。
• 图片中的 title 属性是在鼠标在挪动到元素上的文本提醒。

正确应用 alt 属性

对于应用屏幕阅读器的用户而言，图片是无奈失常展现或者被的浏览的，基于此，咱们须要利用好 alt 属性，或者是上述的aria-label 和 aria-labelledby 属性。

那么，这些属性内的内容应该填充什么呢？咱们须要基于图片的性能加以辨别：

• 信息性图像：以图形形式示意概念和信息的图像，通常是图片、照片和插图。alt 代替文本应该至多是一个简短的形容，传播图像所出现的根本信息。
• 装饰性图像：当图像的惟一目标是为页面增加视觉装璜，而不是传播对了解页面很重要的信息时，如上述所言，应用空的 alt，譬如 alt=""
• 性能图像：用作链接或按钮的图像的代替文本应该形容链接或按钮的性能，而不是视觉图像。此类图像的示例是示意打印性能的打印机图标或提交表单的按钮。
• 文本图像：可读文本有时会呈现在图像中。如果图片不是徽标，请防止图片中呈现文字。然而，如果应用文本图像，代替文本应蕴含与图像中雷同的词。
• 图形和图表等简单图像：为了传播数据或详细信息，提供与图像中提供的数据或信息等效的残缺文本作为代替文本。
• 图像组：如果多张图像传播一条信息，则一张图像的代替文本应传播整组信息。
• 图像映射：蕴含多个可点击区域的图像的代替文本应该为链接集提供整体上下文。此外，每个可独自点击的区域都应该有代替文原本形容链接的目标或目的地。

其实 alt 的学识是十分之多的，如果咱们的页面能做到这一点，那真的算是从根上开始思考，开始优化用户体验。

img 元素与 background 元素的取舍

OK，那么，讲到这里，还有一个有意思的点就很天然的应该被提及。

那就是咱们应该什么时候应用 <img> 元素，什么时候应用 background 内嵌图片？

咱们能够从性能及性能两个方面进行思考：

其实性能上并不是外围思考的点，因为上文咱们也讲到了在明天能够大规模应用是 loading="lazy" 属性，图片能够进行原生反对的懒加载。

咱们在思考选取 <img> 还是 backgroud-image 的时候，更多的还是从图片性能上进行思考。一般来说，作为润饰的且无语义的装饰性图片抉择应用 background-image，而比拟重要的与网页内容相干的就应用 <img> 标签。

因为有语义的图片应用 <img> 展现，它的一个益处在于，当图片加载失败的时候，能够触发元素的 onerror 事件，咱们能够无效的利用这一点，对图片进行异样解决。

图片的异样解决

当图片链接挂了，加载失败了，咱们比拟好的解决形式应该是怎么样呢？

解决的形式有很多种。在张鑫旭老师的这篇文章中 — 图片加载失败后CSS款式解决最佳实际 有一个不错的实际。

外围思路为：

1. 利用图片加载失败，触发 <img> 元素的 onerror 事件，给加载失败的 <img> 元素新增一个款式类
2. 利用新增的款式类，配合 <img> 元素的伪元素，在展现默认兜底图的同时，还能一起展现 <img> 元素的 alt 信息

<img src="test.png" alt="Alt Info" onerror="this.classList.add('error');">

img.error {
    position: relative;
    display: inline-block;
}

img.error::before {
    content: "";
    /** 定位代码 **/
    background: url(error-default.png);
}

img.error::after {
    content: attr(alt);
    /** 定位代码 **/
}

咱们利用伪元素 before ，加载默认谬误兜底图，利用伪元素 after，展现图片的 alt 信息：

<img width=”512″ alt=”image” src=”https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/27073c57823543239d86e4cc28d2357e~tplv-k3u1fbpfcp-zoom-1.image”>

OK，到此，残缺的对图片的解决就算实现了，这也比拟好的论述了为什么，对有语义，有 alt 信息的图片，咱们应该应用 <img> 元素来实现。这是因为，咱们能够在谬误产生的时候，比拟好的对图片进行兜底展现，让用户直观的可能看到 alt 内容。

残缺的 Demo 你能够戳这里看看：

CodePen Demo — 图片解决

当然，上述计划存在两个小问题：

1. 对于每一个 <img> 元素，咱们都须要写一段 onerror="this.classList.add('error');" 代码，有点反复。因而，这个工作也能够交给 JavaScript 全局性的实现，并且，咱们可能须要判断 alt 的值是否为空，在为空时，应用默认图片 alt 兜底文案。
2. 早年间，<img> 等替换元素是没有伪元素的，前面 Chrome/Firefox 浏览器逐步反对了当，<img> 的 src 拉取失败时，反对 <img> 元素的伪元素展现，这才有了上述的计划，然而，目前 Safari 仍不反对这个个性，所以，在 Safari 下，咱们可能失去如下的后果：

<img width=”585″ alt=”image” src=”https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/83574997b1b14c7ab4e56b630d0adc5d~tplv-k3u1fbpfcp-zoom-1.image”>

成果依然还是 OK 的，只是没有了兜底图的展现，在理论应用过程中，须要晓得这一点。

总结一下

本章节，对图片资源的容错及可拜访性解决进行了论述。核心内容在于：

1. 对于图像信息，咱们须要大抵遵循如下可拜访性准则：

   • 所有有意义的 img 元素必须有 alt 属性
   • 提供代替 alt 属性的其余形式
   • 应用辅助技术暗藏装璜图像
2. 正确应用 alt 属性，理解不同场景下 alt 应该填充什么内容
3. img 元素与 background 元素的取舍
4. 图片异样解决的最佳实际

至此，整个古代图片性能优化及体验优化指南到此就圆满结束，整个系列的文章囊括了十分多的新的标准及个性，须要大家在实践中依据理论状况灵便选取应用。

同时，咱们也应该能看到，前端技术仅仅在这一小个畛域，都在一直的迭代翻新。尽管很难，还是须要一直空虚本人跟上新的潮流。共勉。

最初

OK，本文到此结束，心愿本文对你有所帮忙 🙂

想 Get 到最有意思的 CSS 资讯，千万不要错过我的公众号 — iCSS前端趣闻 😄

更多精彩 CSS 技术文章汇总在我的 Github — iCSS ，继续更新，欢送点个 star 订阅珍藏。

如果还有什么疑难或者倡议，能够多多交换，原创文章，文笔无限，满腹经纶，文中若有不正之处，万望告知。