decoding="async" 不能解决大图滚动卡顿，仅将解码移至后台线程，不影响下载、渲染及光栅化耗时；真正瓶颈是高分辨率图片在paint阶段的光栅化开销。
decoding="async" 对大图滚动的实际影响
设为 decoding="async" 并不能解决「大图滚动卡顿」问题——它只控制图片解码线程是否脱离主线程，不改变下载时机、不跳过渲染、也不影响 layout 和 paint 阶段的开销。真正拖慢滚动的，往往是高分辨率图片在 paint 阶段的光栅化（raster）耗时，尤其是未压缩、未适配视口尺寸的 4K+ 图片。
什么时候加 decoding="async" 才有意义
仅当页面存在大量「非首屏、非关键」的 <img>，且它们已通过 loading="lazy" 延迟加载，同时你观察到主线程被图片解码阻塞（DevTools → Performance 面板中看到长任务里有 DecodeImage）时，decoding="async" 才值得加。常见于图文流、商品列表页的尾部图片。
- 必须配合
loading="lazy"使用，否则首屏图提前解码反而增加白屏时间 - 对 WebP/AVIF 等现代格式效果更明显，JPEG/PNG 解码本身较轻，收益有限
- Chrome 115+ 开始默认对
loading="lazy"图片启用异步解码，显式写decoding="async"已非必需
比 decoding 更关键的滚动优化项
大图滚动卡顿，优先检查并调整以下几项：
- 用
contain: paint给图片容器加隔离（如<figure></figure>或<div class="image-wrapper">），避免滚动时全页重绘 <li>确保图片 width/height 属性或 CSS 尺寸固定，防止 layout 波动触发频繁重排</li> <li>服务端返回的图片分辨率严格匹配最大显示尺寸（例如视口宽度 375px，就不要传 2000px 宽原图）</li> <li>用 <code>image-rendering: -webkit-optimize-contrast（Safari）或image-rendering: crisp-edges（部分 Chrome）抑制缩放插值计算
一个稳妥的图片标签组合写法
针对长列表中的大图，推荐这样写（以响应式商品图为例）：
@@##@@
注意：decoding="async" 在这里只是锦上添花；真正起效的是 sizes+srcset 控制资源体积，以及 loading="lazy" 避免非可视区解码和绘制。没有尺寸约束的 decoding，就像给跑车装静音胎却不换发动机——听不见噪音，但加速还是慢。
