decoding="async"仅优化图片解码（CPU）环节，不加速下载；需配合loading="lazy"、显式宽高、srcset/sizes及.webp/.avif格式才生效，否则无效。
不能提速下载，但能减少滚动卡顿——前提是用对场景、配齐条件。
decoding="async"到底优化哪一环
它只管解码（CPU 阶段），不管加载（网络阶段）。图片从服务器下载花了 800ms，decoding="async"不会让它变快；但解码一张 4K .webp 图要 60ms，这 60ms 若在主线程执行，就会卡住滚动、动画、输入响应。设为 async 后，这部分工作被挪到后台线程，主线程继续跑。
常见错误现象：加了 decoding="async" 后首屏图发虚、延迟渲染、甚至空白几帧——不是属性失效，而是用错了位置或漏了配套。
- 只对宽 ≥ 1000px 或体积 ≥ 200KB 的图有可见收益；头像、图标、icon font 加了反而多一次 DOM 属性解析开销
- 必须等图片数据已下载完成才触发解码，所以
Failed to load resource时decoding压根不生效 - Chrome DevTools 的
Performance面板里看Decode Image任务是否从Main Thread移到了Worker Thread，才是真生效
哪些地方必须配合，缺一不可
decoding="async" 不是开关，是协同协议。漏掉任一条件，它就退化成无意义字符串。
立即学习“前端免费学习笔记（深入）”；
-
loading="lazy"：两者常并存，但不是绑定关系；非懒加载图若体积大，仍可单独用async，只是收益下降 - 显式声明
width和height（或aspect-ratio）：否则解码虽异步，后续 layout + paint 频繁重排，Rendering > Paint flashing会大面积闪红 -
srcset必须配sizes：否则浏览器可能选错高清图，体积翻倍，解码压力更大 - 格式优先用
.webp或.avif：JPEG 解码 CPU 开销高，异步收益更明显；现代格式本身压缩率高，进一步降低解码负载 - 不能写在
<picture>或<source>上：decoding只作用于最终渲染的<img>元素
JavaScript 动态插入图片时的坑
用 fetch() + createObjectURL() 插入图时，顺序错了就白写了。
- 必须在设置
img.src之前赋值img.decoding = "async"；Chrome 旧版本（≤ 86）会静默丢弃后设的值 - 框架组件（如
next/image）通常已内置解码逻辑，手动加decoding="async"可能被覆盖，得 inspect DOM 确认最终<img>是否带该属性 - JS 懒加载库（如 lozad.js）在滚动时动态替换
src，会覆盖原生decoding设置；禁用 JS 后测试，才能判断是属性失效还是被覆盖
sync / async / auto 到底怎么选
别信 auto，也别默认不写——现代浏览器实际行为和你直觉相反。
-
decoding="auto"：规范说“由浏览器决定”，但 Chrome ≥ 87、Firefox ≥ 78、Safari ≥ 16.4 实际都按sync处理；写了等于白写 -
decoding="sync"：必须显式写，且只用于两类场景——需要立即读img.naturalWidth做布局计算，或动画帧序列首帧要求像素级同步；滥用会导致主线程阻塞加剧 -
decoding="async"：适用于非首屏、非焦点区域的大图，比如瀑布流商品图、评论头像列表、loading="lazy"触发后的缩略图
真正难处理的是边界场景：比如 canvas 绘图前既要确保解码完成，又不能卡主线程——这时候得结合 img.decode() API 手动 await，而不是只靠属性。
