decoding="async"仅在图片数据已下载完成且解码成为主线程瓶颈时才减少卡顿；适用于宽≥1000px或体积≥200KB的JPEG/WebP图，须配合loading="lazy"、显式宽高和现代格式才有效。
decoding="async"什么时候真能减少主线程卡顿
它只在图片数据已下载完成、但解码本身拖慢主线程时起作用。不是“加了就快”，而是必须满足三个前提：图已加载完毕、解码是瓶颈、且浏览器支持该行为。对小图（比如 16x16 图标或 50KB 以下的 WebP）加 decoding="async" 基本没收益，反而多一次属性解析开销。
实测有效场景集中在：
- 宽 ≥
1000px或体积 ≥200KB的 JPEG/WebP 图（如商品列表缩略图、瀑布流大图） -
loading="lazy"触发后进入视口的图——此时数据通常已缓存或快速下载完，解码成为唯一阻塞点 - JS 动态插入的图，用
fetch()+createObjectURL()加载的大图
为什么写了 decoding="async" 还卡
不是属性失效，而是被其他环节抵消或覆盖：
-
srcset没配sizes，浏览器误选高清图（比如本该加载1x却拉了2x），体积翻倍，解码压力反而更大 - 父容器用了
overflow: hidden或transform: translateZ(0)，导致 Intersection Observer 失效，loading="lazy"根本不触发，图压根不加载，decoding更无从谈起 - JS 懒加载库在滚动时才动态替换
src，覆盖了原生decoding="async"设置（禁用 JS 后测试一下就清楚） - 没声明
width/height或aspect-ratio，解码虽异步，但后续绘制频繁重排，Chrome DevTools > Rendering > Paint flashing 会大面积闪红
必须和哪些属性一起用才安全
单独写 decoding="async" 几乎没用，它必须协同生效：
立即学习“前端免费学习笔记（深入）”；
-
loading="lazy"：确保图不在首屏立即加载，避免解码集中爆发 - 显式
width和height（HTML 属性，非 CSS）：预留空间，防止布局偏移（CLS），也让浏览器能提前规划渲染流 - 现代格式（
WebP或AVIF）：同尺寸下体积更小、解码更快；JPEG 虽支持decoding="async"，但解码耗时仍远高于 WebP -
fetchpriority="high"（仅对首屏关键图）：抢带宽优先级，避免因网络排队导致解码延迟等待
错误示例：<img src="hero.jpg" decoding="async"> —— 首屏图没 loading="eager"，也没 width/height，控制台出现 Failed to load resource 就说明它根本没机会工作。
怎么验证它是否真起效
不能只看代码有没有写，得看运行时表现：
- Chrome DevTools → Performance 面板录制滚动操作，筛选
Decode Image任务，观察其是否从主线程移到后台线程（显示为灰色而非红色） - Rendering → 勾选
Paint flashing，快速滚动，非首屏图片若仍有大面积黄色闪烁，说明仍在同步解码 - Safari 16.4 之前版本静默忽略该属性，旧版 iOS WebView 同样不支持——不是报错，而是当不存在，需用
@supports (decoding: async)做降级 - Webpack/Vite 构建时若用了 HTML 插件自动压缩，可能删掉未知属性，需配置保留
decoding
最常被忽略的一点：decoding 控制的是解码时机，不是下载速度。如果图本身没压缩、没裁切、没转 WebP，加再多属性也卡。真正省下的时间，90% 来自服务端预处理，而不是前端多写一行 decoding="async"。
