decoding="async"仅在图像数据已下载完成且解码成为CPU瓶颈时减少卡顿，适用于宽≥1000px或体积≥200KB的大图、懒加载图、瀑布流缩略图及JS动态插入图，须配合loading="lazy"、显式尺寸和现代格式才有效。

decoding="async" 什么时候真能减少卡顿

它只在图像数据已下载完成、但解码本身拖慢主线程时起作用。不是所有图都适合——decoding="async"对宽 ≥ 1000px 或体积 ≥ 200KB 的 JPEG/WebP 图有效，对小图（如头像、图标）基本没收益。

典型有效场景包括：

• 滚动区域里的商品缩略图、瀑布流画廊、次屏 banner
• loading="lazy" 的图，在进入视口前就设好 decoding="async"
• 用 fetch() + createObjectURL() 动态插入的大图
• 批量渲染（100+ 张）中高分辨率图时，主线程 “Image Decode” 耗时实测可降 40–60%

反例：首屏 hero.jpg 加了 decoding="async" 却没配 loading="eager"，图还没下载完，属性压根不触发；控制台出现 Failed to load resource 就说明它根本没机会工作。

为什么写了 decoding="async" 还卡

不是属性失效，而是被其他行为抵消或覆盖：

• srcset 没配 sizes，浏览器选错高清图（比如本该 1x 却加载了 2x），体积翻倍，解码压力反而更大
• 父容器用了 overflow: hidden + loading="lazy"，图片永远不进入视口，加载都不触发，更别说解码
• JS 懒加载库在滚动时才动态替换 src，覆盖了原生 decoding 设置（禁用 JS 后测试一下就清楚）
• 没声明 width/height 或 aspect-ratio，解码虽异步，但后续绘制频繁重排，Chrome DevTools > Rendering > Paint flashing 会大面积闪红

单独写 decoding="async" 几乎没用，它必须和 loading="lazy"、显式尺寸、现代图片格式（WebP/AVIF）协同生效。

sync / async / auto 三个值怎么选

auto 是规范默认值，但当前所有主流浏览器（Chrome ≥ 87、Firefox ≥ 78、Safari ≥ 16.4）实际都按 sync 处理——写了等于白写，别用。

• decoding="sync"：仅用于两类场景——需要立即读取 img.naturalWidth 做布局计算，或动画帧序列首帧需严丝合缝。日常 banner、文章配图、用户头像都不属于这个范畴
• decoding="async"：非首屏、非关键、大尺寸/大体积图的明确推荐，但必须搭配 loading="lazy" 和显式尺寸声明才稳妥
• 完全不写该属性：对首屏 banner、logo、主图最稳妥，默认行为反而更稳定

注意：decoding 只作用于 <img> 元素，对 <picture>、<source> 或 CSS background-image 完全无效。

框架里要不要手动加 decoding="async"

大多数现代框架（如 Next.js 的 next/image、Nuxt 的 NuxtImg）已在组件内部做了等效优化，手动加 decoding="async" 不仅无效，还可能被构建时移除。

判断方法很简单：打开 DevTools，检查最终渲染出的 DOM 中 <img> 标签是否真有 decoding="async"。如果没了，说明框架已接管或忽略。

JavaScript 动态创建 img 时，decoding 必须在设置 src 之前赋值，否则旧版 Chrome 会静默丢弃。正确写法是：

const img = new Image();
img.decoding = 'async';
img.src = 'photo.jpg';

真正决定解码体验的，从来不是单个属性，而是 decoding + loading + width/height + 图片格式四者协同；漏掉任一环，async 就只是个没用的字符串。