decoding="async"能减少主线程阻塞，因其将CPU密集型图像解码移交后台线程，使主线程及时响应滚动、点击等操作；实测20张JPEG图解码耗时从80ms+降至10–20ms。
decoding 属性不控制图片加载，只影响浏览器拿到数据后、在主线程上何时执行像素解码——这是造成滚动卡顿、点击无响应的常见隐形瓶颈。
decoding="async" 为什么能减少主线程阻塞
图像解码（尤其是 JPEG/WebP/AVIF）是 CPU 密集型操作。默认 sync 模式下，浏览器必须等解码完成才继续渲染或响应用户操作；async 则提示浏览器把这一步交给后台线程，主线程可立即处理滚动、点击、动画等任务。
- 实测中，20 张 1200×800 的 JPEG 进入视口时，
decoding="async"可将主线程“Image Decode”耗时从 80ms+ 压至 10–20ms - 该收益在低端 Android 设备上更明显，因 CPU 解码单帧常超 50ms
-
auto不是安全默认——当前多数浏览器对非sync图实际走异步，但行为不可控，不建议依赖
什么时候加 decoding="async" 才真正有用
它起效的前提是：图片已加载完成（loaded），但尚未绘制（paint），此时解码成为瓶颈。
- 适用：懒加载图（
loading="lazy"）、商品列表缩略图、画廊瀑布流、JS 动态插入的大图（如fetch()+createObjectURL()） - 无效甚至有害：小图标（≤ 4KB）、头像（≤ 100×100）、首屏关键图（如 banner）、未压缩的 PNG（解码快，网络才是瓶颈）
- 必须配合
width/height使用，否则即使解码异步，仍会因尺寸未知引发 CLS（累积布局偏移）
decoding 属性容易被忽略的关键限制
它不是万能开关，很多看似合理写法其实失效或反效果。
立即学习“前端免费学习笔记（深入）”；
-
<source>和<picture>元素上设decoding会被完全忽略，必须作用于最终渲染的<img> - JavaScript 动态创建
img时，decoding必须在设置src之前赋值，否则旧版 Chrome 会静默丢弃 - 与
fetchpriority="high"并存时，下载优先级提升，但解码仍排队——大图（如 4K WebP）解码本身就要 80ms+，异步只能换线程，不能省时间 - 框架组件（如
next/image）通常已内置解码优化，手动加decoding="async"可能被覆盖，需检查最终生成的 DOM 确认是否生效
真正决定解码体验的，从来不是单个属性，而是 decoding + loading + width/height + 图片格式（WebP/AVIF）四者协同；漏掉任一环，async 就只是个没用的字符串。
