decoding="async"必须配合loading="lazy"且作用于最终渲染的<img>标签，仅在图片数据下载完成、像素转换耗CPU时生效，适用于宽≥1000px或体积≥200KB的大图、瀑布流缩略图等非首屏场景。
decoding="async"必须配loading="lazy"，但顺序和位置有讲究
单独写 decoding="async" 对长列表大图几乎没用——它只在图片数据已下载完成、但像素转换耗 CPU 时起作用。如果图片还没开始加载，解码根本无从谈起。loading="lazy" 负责延迟请求，decoding="async" 负责不卡主线程，二者是分阶段协作关系。
实操建议：
-
loading="lazy"必须写在<img>标签上，不能只靠 JS 懒加载库动态替换src（那样会丢掉原生属性） -
decoding="async"必须写在最终渲染的<img>上，<source>或<picture>里设无效 - Vue/React 中动态创建
img元素时，decoding属性要在设置src之前赋值，否则旧版 Chrome 会静默丢弃 - Webpack/Vite 构建时若用了 HTML 压缩插件（如
html-webpack-plugin），需显式配置保留decoding属性，否则会被删掉
哪些图该加decoding="async"，哪些绝对不能加
不是所有图片加了 decoding="async" 都能变快；加错了反而让首屏图发虚、延迟渲染，甚至出现短暂空白。
该加的场景（满足任一即可）：
立即学习“前端免费学习笔记（深入）”；
- 宽 ≥ 1000px 或体积 ≥ 200KB 的 JPEG/WebP/AVIF 图（小图如头像、图标加了基本没收益）
- 瀑布流/商品列表中批量出现的缩略图（实测 100+ 张大图滚动时，主线程解码耗时降 40–60%）
- 通过
fetch()+createObjectURL()动态插入的图，且你已提前设好decoding="async"
绝对不该加的场景：
- 首屏关键图（如 banner、logo、登录头像）——应设
decoding="sync"或干脆不设（默认行为更稳妥） - 还没下载完的图（控制台显示
Failed to load resource），此时decoding压根不执行 - 父容器用了
overflow: hidden且未设合适rootMargin，导致图片永远不触发 Intersection Observer，loading="lazy"不生效，decoding也白搭
为什么写了decoding="async"还是卡？常见覆盖链路
不是属性失效，而是被其他行为覆盖或抵消。Chrome DevTools 的 Rendering → Paint flashing 是最直接的验证方式：快速滚动时，非首屏图仍有大面积黄色闪烁，说明仍在同步解码。
典型干扰项：
-
srcset没配sizes，浏览器选错高清图，体积翻倍，解码压力反而更大 - 没设
width/height或aspect-ratio，解码虽异步，但后续绘制频繁重排，Paint flashing 闪红 - 用了 Next.js 的
next/image或 Nuxt 的NuxtImg等框架组件，它们通常已内置解码逻辑，手动加decoding="async"可能被覆盖——务必检查最终生成的 DOM 是否真实存在该属性 - Safari 16.4 之前完全不支持
decoding，旧版 iOS WebView 会静默忽略（不是报错，而是当不存在）
sync / async / auto 三个值怎么选才不踩坑
auto 是规范默认值，但当前所有主流浏览器（Chrome ≥ 87、Firefox ≥ 78、Safari ≥ 16.4）实际都按 sync 处理——写了等于白写，别用。
选择逻辑很直接：
-
decoding="sync"：仅用于极少数必须像素级同步的场景，比如 canvas 绘图前要读img.naturalWidth做布局计算，或动画帧序列首帧需严丝对齐 -
decoding="async"：绝大多数非首屏大图的首选，明确告诉浏览器“这张图可以异步解码” -
decoding="auto"：兼容性好但不可控，不建议依赖；尤其在 SSR 页面中，服务端预渲染时无法预测客户端浏览器行为
真正起效的关键点，往往藏在那行不起眼的 decoding="async" 里——但它必须出现在正确的位置、配合正确的资源状态、避开框架封装和构建工具的过滤，才算真正落地。
