decoding="async"能缓解长列表滚动卡顿，因其将像素解码从主线程移至后台线程，避免宽≥1000px或体积≥200kb的大图集中解码阻塞渲染；适用于配合loading="lazy"的非首屏图、动态插入图及瀑布流缩略图，但不适用于首屏关键图或小图标。
decoding="async"为什么能缓解长列表滚动卡顿
解码一张宽高超过 1000px 的 JPEG 或 WebP 图片，主线程可能被占用 60–80ms；长列表里几十张图挨个解码，就会在用户快速滚动时集中触发，造成肉眼可见的掉帧。decoding="async" 不是让图片“加载更快”，而是把像素解码这一步从渲染主线程移到后台线程——滚动、点击、动画这些交互不再被卡住。
哪些图片必须加 decoding="async"
不是所有 <img> 都值得加，加错反而引入解析开销或首屏空白：
- 宽 ≥ 1000px 或体积 ≥ 200KB 的位图（如商品主图、瀑布流大缩略图）
- 配合
loading="lazy"使用的非首屏图（进入视口时才解码，此时主线程正忙） - 通过
fetch()+createObjectURL()动态插入的图，且已提前设置好decoding="async" - 明确不用于首屏关键路径的图（比如评论头像、二级页面缩略图）
小图标（16×16）、SVG、已压缩的 WebP（
写了 decoding="async" 还卡？常见抵消原因
属性本身生效很快，但容易被其他行为覆盖或抵消：
-
srcset没配sizes，浏览器选了 4K 版本，体积翻倍，解码压力更大 - 父容器用了
overflow: hidden+loading="lazy"，图片永远不进入视口，根本没机会加载和解码 - JS 懒加载库（如 lozad）在滚动时动态替换
src，覆盖了原生decoding设置——禁用 JS 后检查 DOM 就能确认 - 没设
width/height或aspect-ratio，解码虽异步，但后续绘制频繁重排，DevTools 的 Rendering → Paint flashing 会大面积闪红 -
<picture></picture>或<source></source>上写了decoding—— 完全无效，必须写在最终渲染的<img>标签上
构建和框架中容易被忽略的细节
现代构建工具和框架会静默删掉或覆盖这个属性：
- Webpack/Vite 的 HTML 压缩插件（如
html-webpack-plugin）默认删未知属性，需显式配置保留decoding - Vue/React 中动态创建
<img>，decoding必须在设置src之前赋值，否则旧版 Chrome 会丢弃 - Next.js 的
next/image、Nuxt 的nuxt-img等组件通常已内置解码优化，手动加decoding="async"可能被覆盖，务必检查最终生成的 DOM 是否真实存在该属性 - Safari 16.4 之前完全不支持，旧版 iOS WebView 会静默忽略（不是报错），需降级兼容或服务端特征检测
真正起效的关键，往往就藏在那一行不起眼的 decoding="async" 里——但它只在解码耗 CPU 且图片已下载完成时才开始工作，别指望它解决网络延迟或布局抖动问题。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
