decoding="async"能减少瀑布流丢帧，因其将大图解码从主线程移至后台线程，避免CPU占用飙升导致60fps骤降至30fps以下；适用于宽≥1000px或体积≥200KB的JPEG/WebP/AVIF图、lazy加载已进入视口的图、fetch动态插入图，须配合loading="lazy"、显式宽高及现代格式。
decoding="async"在瀑布流中为什么能减少掉帧
它不加快下载，只把图片解码从主线程挪到后台线程。瀑布流滚动时，大量图片进入视口触发解码，若都在主线程同步跑，CPU 占用飙升，直接导致 60fps 掉到 30fps 甚至更低。Chrome DevTools 的 Performance 面板里能看到大量 Decode Image 任务堆在主线程上——decoding="async" 就是专门治这个的。
哪些瀑布流图片必须加decoding="async"
不是所有图都适合，加错反而拖慢首屏或引发模糊：
- 宽 ≥ 1000px 或体积 ≥ 200KB 的 JPEG/WebP/AVIF 图（小图如头像、图标加了基本没收益，还多一次属性解析）
- 被
loading="lazy"控制、且已进入视口开始解码的图（注意：图片还没下载完时，该属性完全不生效） - 批量插入的动态图（比如 fetch 后用
createObjectURL()插入，必须提前设好decoding="async"） - 包裹在
<picture>中的图，属性必须写在最外层<img>上，写在<source>里无效
配合loading="lazy"时容易踩的三个坑
decoding="async" 和 loading="lazy" 不是“开了就稳”，组合不当照样卡：
- 没设
width和height属性 → 浏览器无法预留空间，图片加载后重排（CLS），视觉上“跳”比卡更伤体验 - 父容器用了
overflow: hidden或transform: translateZ(0)→ 干扰 Intersection Observer，loading="lazy"失效，decoding="async"也失去触发时机 - 图片格式没优化 → 解码再快，5MB 的 PNG 下载要 2s，
decoding="async"完全无意义；优先转 WebP/AVIF + CDN 缓存
实测有效的最小配置模板
瀑布流每张图至少要带这四样，缺一不可：
立即学习“前端免费学习笔记（深入）”；
<img src="item-1.jpg" srcset="item-1-400.jpg 400w, item-1-800.jpg 800w" sizes="(max-width: 480px) 100vw, 50vw" width="800" height="600" loading="lazy" decoding="async" alt="商品图">
注意：srcset 和 sizes 必须配对，否则可能拉取远超需要的大图；width/height 必须是 HTML 属性（不是 CSS），SSR 渲染时才能保留占位；decoding="async" 对 >1MB 图收益最明显，但若页面里混着几十张未压缩的 PNG，再怎么调属性也救不回帧率。
