decoding="async"仅缓解大图解码导致的主线程阻塞，将cpu密集型像素解码移至后台线程，不加速下载或减小体积；对≥800px宽/高的位图（如2000×1500 jpeg）有效，小图、svg及高度压缩webp无效。
decoding="async" 能缓解主线程阻塞，但只对大图解码有效
它不加快下载，也不减少图片体积，只把像素解码（CPU 密集操作）从主线程移到后台线程。实测中，一张 2000×1500 的 JPEG 解码可能占用主线程 80ms 以上；滚动时若同时触发 5 张这样的图解码，用户会明显感知卡顿。decoding="async" 能让这 5 次解码并行在后台执行，主线程继续响应滚动、点击等交互。
但对小图基本无效：16×16 图标、SVG、或已高度压缩的 .webp（Decode Image 占比，就别硬加。
- 真正受益场景：宽 ≥ 800px 或体积 ≥ 200KB 的位图（尤其 JPEG）
- 无效场景：头像、图标、内联 SVG、
<picture></picture>中的<source></source>（属性必须写在最终渲染的<img>上） - 旧版 Safari（
为什么写了 decoding="async" 还卡？大概率是三件事没配齐
单独加 decoding="async" 几乎没用。它必须和以下三项协同才起效：
-
loading="lazy"：避免首屏外图片一渲染就批量下载+解码，否则异步也救不了 - 显式
width和height（或aspect-ratio）：防止解码后重排，CLS 比解码卡顿更伤体验 -
srcset+sizes配合现代格式（.webp/.avif）：否则浏览器可能拉取 4K 图解码，异步也扛不住
漏掉任一环，decoding="async" 就只是 DOM 里一个安静的字符串。用 Chrome DevTools 打开 Rendering → Paint flashing，快速滚动，如果非首屏图仍有大面积黄色闪烁，说明仍在同步解码——不是属性没生效，而是被其他问题掩盖了。
动态插入 img 时 decoding 必须在 src 赋值前设置
JavaScript 创建 <img> 元素时，顺序错了就白写了：
- ✅ 正确：
const img = document.createElement('img'); img.decoding = 'async'; img.src = '/path.jpg'; - ❌ 错误：
img.src = '/path.jpg'; img.decoding = 'async';（旧版 Chrome ≤ 86 会静默丢弃） - React/Vue 中别在
useEffect或mounted后再设——那时元素已挂载，时机太晚；得在 JSX/模板里直接写decoding="async"，或确保渲染函数生成的 DOM 带该属性 - 用
createObjectURL()时同理：先设decoding，再赋src
sync / async / auto 三个值到底怎么选
别信“auto 是默认最安全”——现代浏览器（Chrome ≥ 87、Firefox ≥ 78、Safari ≥ 16.4）对未声明 decoding 的 <img>，实际行为接近 sync。所以不写 ≠ 异步，写了 auto ≈ 白写。
-
decoding="sync"：仅用于必须像素级同步的极少数场景，比如 canvas 绘图前要读img.naturalWidth做布局，或动画首帧需严丝合缝；滥用会导致首屏延迟加剧 -
decoding="async"：非首屏、非焦点区域的大图首选，如商品列表缩略图、评论头像（若尺寸够大）、瀑布流卡片图 - 框架组件（如
next/image、Ant Design Table）通常已内置解码优化，手动加可能被覆盖；最终检查 DOM，确认生成的<img>元素上真有decoding="async"
真正影响感知性能的，从来不是 decoding 单独开关。它只是最后一层微调——前面尺寸、格式、懒加载、CDN 缓存没理顺，加了也看不出差别。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
