共计 3721 个字符，预计需要花费 10 分钟才能阅读完成。
在这里我将列出 8 种图片加载优化技术来缩小宽带应用和 cpu 占用。我将应用 html 例子来更好的重现这个后果。其中一部分技术曾经相当稳固，而另外一些则有些新鲜。现实状况下，您最喜爱的公布 Web 文档的机制（例如 CMS，动态站点生成器或 Web 应用程序框架）可实现所有这些现成的性能。
在本文结尾处，我将应用提供了此处概述的所有优化的技术更新列表。
Google’s Core Web Vitals 通过以下计划来优化所有的元素
- 通过缩小字节，缓存和提早加载来最大水平地缩小最大的内容绘制（LCP）
- 放弃累积布局偏移（CLS）为零
- 通过缩小（主线程）CPU 使用率来缩小第一输出提早（FID）
查看此实例图片的代码，来理解这些技术吧：
- 响应式布局
这是一种家喻户晓的技术，能够使图像应用可用的程度空间直到其最大尺寸，同时保留宽高比。
2020 年的新性能是，如果为 img 元素提供了 width 和 height 属性，则网络浏览器将在图像加载之前为其保留正确的垂直空间。
这样能够防止累积布局偏移（CLS）。
<style>
img {
max-width: 100%;
height: auto;
}
</style>
<!-- Providing width and height is more important than ever. -->
<img height="853" width="1280" … />- 延时渲染
第二种技术是更前沿。
新的 CSS 属性 content-visibility：auto 批示浏览器在图像凑近屏幕之前不要搅扰布局。
这具备各种益处，但最重要的益处可能是，浏览器将不会费神地解码咱们含糊的占位符图像或图像自身，除非必须这样做，这样能够节俭 CPU。
这篇文章的晚期版本介绍了如何应用 contain-intrinsic-size 来影响 content-visibility: auto，然而从 Chromium 88 开始，图片不在须要提供 width 和 height。
其余浏览器引擎（01/27/2021）尚未实现 content-visibility: auto，并且在这种非凡状况下可能会追寻 Chromium 的倒退。
所以，是的，这当初要简略得多！
main img {
/* Only render when in viewport */
content-visibility: auto;
}</style>- AVIF
AVIF 是已在 Web 浏览器中采纳的最新图像格式。
Chromium 浏览器目前反对该性能，并且在 Firefox 中带有标记即可应用。
尚不反对 Safari，但思考到 Apple 是该格局的支持者，咱们能够期待未来
的反对。
AVIF 值得注意，因为它以十分重要的形式始终胜过 JPEG。
这与 WebP 有所不同，WebP 并不总是产生比 JPEG 小的图像，并且因为不足对渐进式加载的反对而实际上可能会产生净损失。
要实现 AVIF 的渐进加强，请应用 picture 元素。
理论的 img 元素嵌套在 picture 中。
这可能会十分令人困惑，因为对于没有 picture 反对的浏览器，有时会将 img 做为回退，但基本上，picture 元素仅有助于 src 抉择，而自身没有布局。
绘制的元素（以及要设置款式的元素）是 img 元素。
直到最近，在服务器端理论对 AVIF 图像进行编码依然绝对艰难，然而对于像 Sharp 这样的最新版本的库，当初变得微不足道了。
<picture>
<source
sizes="(max-width: 608px) 100vw, 608px"
srcset="
/img/Z1s3TKV-1920w.avif 1920w,
/img/Z1s3TKV-1280w.avif 1280w,
/img/Z1s3TKV-640w.avif 640w,
/img/Z1s3TKV-320w.avif 320w
"type="image/avif"
/>
<!-- snip lots of other stuff -->
<img />
</picture>
您可能曾经留神到下面的代码段中的 srcset 和 size 属性。
应用 w 选择器，它会依据基于 sizes 属性（媒体查问表达式）计算得出的宽度，依据将图像绘制到用户设施时将应用的物理像素，来通知浏览器应用哪个 URL。
这样，浏览器将始终下载尽可能小的图像，从而为用户提供最佳的图像品质。
或者，例如，如果用户抉择了某种数据保留模式，它可能会抉择较小的图像。
如果浏览器不反对 AVIF, 能够应用如下 fallbacks
为仅反对旧版图像格式的浏览器提供更多带有 srcset 的源元素。
<source
sizes="(max-width: 608px) 100vw, 608px"
srcset="
/img/Z1s3TKV-1920w.webp 1920w,
/img/Z1s3TKV-1280w.webp 1280w,
/img/Z1s3TKV-640w.webp 640w,
/img/Z1s3TKV-320w.webp 320w
"type="image/webp"
/>
<source
sizes="(max-width: 608px) 100vw, 608px"
srcset="
/img/Z1s3TKV-1920w.jpg 1920w,
/img/Z1s3TKV-1280w.jpg 1280w,
/img/Z1s3TKV-640w.jpg 640w,
/img/Z1s3TKV-320w.jpg 320w
"type="image/jpeg"
/>- 缓存不可变的 URL
在图像的 URL 中嵌入图像中字节的哈希值。
在下面的示例中，我应用图像 URL 中的 Z1s3TKV 进行了此操作。
这样，如果图像更改，URL 就会更改，并且您能够别离对图像利用有限的缓存过期。
您心愿缓存头看起来像这样的 cache-control：public，max-age = 31536000，immutable。
immutable 是在语义上正确的缓存管制值，但可怜的是，它在浏览器中并未失去广泛支持（我在用 Chrome 浏览器查看）。
max-age = 31536000 是要缓存一年的后备工夫。
public 对于使您的 CDN 缓存图像并从边缘传递图像很重要。
但仅在从隐衷角度思考适合的状况下才应用它
- 提早加载
在 img 中增加 loading =“lazy”会批示浏览器仅在图像离屏幕更近且可能会理论出现时才开始获取图像。
<img loading="lazy" … />- 异步编译
在 img 中增加 decoding =“async”能够使浏览器具备从主线程解码图像的权限，从而防止了用户对用于解码图像的 CPU 工夫的影响。
这应该没有显著的毛病，除了因为遗留起因不能总是默认值。
<img decoding="async" … />- 含糊的占位符
含糊占位符是一种内联图像，它向用户提供了一些图像概念，这些图像最终将加载而无需从网络中获取字节。
<img style="
…
background-size: cover;
background-image:
url('data:image/svg+xml;charset=utf-8,%3Csvg xmlns='http%3A//www.w3.org/2000/svg'xmlns%3Axlink='http%3A//www.w3.org/1999/xlink'viewBox='0 0 1280 853'%3E%3Cfilter id='b'color-interpolation-filters='sRGB'%3E%3CfeGaussianBlur stdDeviation='.5'%3E%3C/feGaussianBlur%3E%3CfeComponentTransfer%3E%3CfeFuncA type='discrete'tableValues='1 1'%3E%3C/feFuncA%3E%3C/feComponentTransfer%3E%3C/filter%3E%3Cimage filter='url(%23b)'x='0'y='0'height='100%25'width='100%25'xlink%3Ahref='data%3Aimage/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAkAAAAGCAIAAACepSOSAAAACXBIWXMAAC4jAAAuIwF4pT92AAAAs0lEQVQI1wGoAFf/AImSoJSer5yjs52ktp2luJuluKOpuJefsoCNowB+kKaOm66grL+krsCnsMGrt8m1u8mzt8OVoLIAhJqzjZ2tnLLLnLHJp7fNmpyjqbPCqLrRjqO7AIeUn5ultaWtt56msaSnroZyY4mBgLq7wY6TmwCRfk2Pf1uzm2WulV+xmV6rmGyQfFm3nWSBcEIAfm46jX1FkH5Djn5AmodGo49MopBLlIRBfG8yj/dfjF5frTUAAAAASUVORK5CYII='%3E%3C/image%3E%3C/svg%3E');
"
…
/>英文原文：https://www.industrialempathy…
张鑫旭 AVIF 图片格式简介
和应用 https://www.zhangxinxu.com/wo…