decoding="async"仅在图像已下载完成但解码拖慢主线程时减少卡顿，适用于宽≥1000px或体积≥200KB的JPEG/WebP图，对小图无效；配合loading="lazy"、显式宽高及现代格式才生效。
decoding="async" 什么时候真能减少主线程卡顿
它只在图像数据已下载完成、但解码本身拖慢主线程时起作用。不是所有图都适合——decoding="async" 对宽 ≥ 1000px 或体积 ≥ 200KB 的 JPEG/WebP 图有效，对小图（如头像、图标）基本没收益。
典型有效场景包括：
- 滚动区域里的商品缩略图、瀑布流画廊、次屏 banner
-
loading="lazy"的图，在进入视口前就设好decoding="async" - 用
fetch()+createObjectURL()动态插入的大图 - 批量渲染（100+ 张）中高分辨率图时，主线程 “Image Decode” 耗时实测可降 40–60%
为什么 decodingsync 和 async 的行为差异这么大
decoding 控制的是解码时机，不是加载策略。浏览器默认是 auto，但 Chrome 78+、Firefox 95+、Safari 16.4+ 实际更倾向 sync，尤其对非懒加载图片——这意味着你得主动改。
三种取值的实际表现：
立即学习“前端免费学习笔记（深入）”；
-
sync：强制主线程同步解码，适合首屏关键图（如 banner、logo），确保不闪、不跳；但会阻塞渲染线程 -
async：明确告诉浏览器“这张图可以异步解码”，适合非首屏、非焦点区域的图片 -
auto：由浏览器自行判断，目前兼容性好但不可控，不建议依赖
decoding="async" 配合 loading="lazy" 容易踩的坑
两者不互斥，但存在隐式协同： loading="lazy" 延迟加载，decoding="async" 延迟解码。但注意：
- 如果图片已加载完成（比如通过预加载或缓存），
decoding="async"仍生效，而loading="lazy"就不再起作用了 - 首屏图设
decoding="async"却没配loading="eager"，图还没下载完，属性压根不触发；控制台出现Failed to load resource就说明它根本没机会工作 - Safari 16.4 之前完全不支持，旧版 iOS WebView 会静默忽略——不是报错，而是当不存在
怎么验证 decoding="async" 是否真的起效
打开 Chrome DevTools → Performance 面板 → 录制一次滚动操作 → 查看主线程 Flame Chart 中的 Decode Image 任务占比。若该任务持续占用 >30ms 且频繁出现，加了 decoding="async" 后应明显缩短或移出主线程。
必须配合以下条件才可能看到效果：
-
loading="lazy"（或图片已缓存，但尚未解码） - 显式设置
width和height（防布局偏移） - 使用现代格式（WebP/AVIF），JPEG 需 ≥200KB 或 ≥1000px 宽
强行给 16×16 favicon 或 SVG 加 decoding="async" 不仅无效，还会增加 HTML 解析开销。
