decoding="async"仅对宽≥1000px或体积≥200KB的大图、懒加载图及批量缩略图有效，可异步解码缓解主线程阻塞；小图、首屏关键图滥用反致发虚或延迟，且需配合loading="lazy"、显式尺寸声明及现代图片格式才能真正提升感知性能。
decoding 属性不是“加速图片加载”，而是把解码这一步从主线程挪走——加对了能明显减少滚动卡顿，加错了反而让首屏图发虚或延迟渲染。
decoding="async" 什么时候真正起作用
它只在解码本身成为瓶颈时才有效，也就是图像数据已下载完成、但像素转换耗 CPU 的阶段。常见于：
- 宽 ≥ 1000px 或体积 ≥ 200KB 的 JPEG/WebP 图（小图如头像、图标加了几乎没收益）
- 懒加载图片（
loading="lazy"），因为用户不会立刻看到，异步解码不伤体验 - 瀑布流/商品列表中批量出现的缩略图（实测 100+ 张大图滚动时，主线程解码耗时降 40–60%）
- 通过
fetch()+createObjectURL()动态插入的图，且你已提前设好decoding="async"
如果图片还没下载完，decoding 根本没机会执行；控制台看到 Failed to load resource 或 net::ERR_CONNECTION_REFUSED，说明属性压根没生效。
为什么写了 decoding="async" 还卡
不是属性失效，而是被其他行为覆盖或抵消：
立即学习“前端免费学习笔记（深入）”；
-
srcset没配sizes，浏览器选错高清图，体积翻倍，解码压力反而更大 - 父容器用了
overflow: hidden+loading="lazy"，图片永远不进入视口，加载都不触发 - JS 懒加载库在滚动时才动态替换
src，覆盖了原生decoding设置（禁用 JS 后测试一下就清楚） - 没设
width/height或aspect-ratio，解码虽异步，但后续绘制频繁重排，Chrome DevTools 的Rendering > Paint flashing会大面积闪红
sync / async / auto 三个值怎么选
auto 是规范默认值，但当前所有主流浏览器（Chrome ≥ 87、Firefox ≥ 78、Safari ≥ 16.4）实际都按 sync 处理——写了等于白写，别用。
-
decoding="sync"：仅用于极少数必须像素级同步的场景，比如canvas绘图前要读img.naturalWidth做布局计算，或动画帧序列首帧需严丝合缝 -
decoding="async"：非首屏、非关键、大尺寸/大体积图的明确推荐，但必须搭配loading="lazy"和显式尺寸声明才稳妥 - 完全不写该属性：对首屏 banner、logo、主图最稳妥，默认
sync能保证视觉立即稳定
框架里（如 Next.js 的 next/image）通常已内置解码优化，手动加 decoding="async" 不仅无效，还可能被移除——检查最终渲染出的 DOM 就知道。
容易被忽略的硬性限制
decoding 只作用于 <img> 元素，对 <picture>、<source> 或 CSS background-image 完全无效。它只是提示，浏览器仍可能因内存紧张或 CPU 负载高而降级为同步解码。旧版 Safari（≤ 15.4）和部分安卓 WebView 会静默忽略，无副作用但也不起效。真正决定感知性能的，从来不是单个属性，而是 width/height、现代格式（WebP/AVIF）、响应式 srcset + sizes 与 decoding 的组合落地。
