decoding属性不优化解码速度，只改变解码线程和时机；设为async可避免主线程阻塞，但仅在图像数据已下载完成且像素转换耗CPU时生效，需配合loading="lazy"、宽高声明、srcset/sizes及.webp/.avif格式才有效。

decoding 属性不优化“解码速度”，它只改变解码发生的线程和时机。加了 decoding="async"，图片不会解得更快，但能避免卡住主线程——这才是你滚动卡顿、交互延迟的真正病灶。

decoding="async" 什么时候才真正起作用

它只在图像数据已下载完成、且像素转换（尤其是大图 JPEG/WebP）耗 CPU 时生效。不是所有图都值得加：

• 宽 ≥ 1000px 或体积 ≥ 200KB 的位图（如商品主图、Banner 背景）
• loading="lazy" 图片进入视口后集中触发解码的场景（瀑布流、长列表）
• 通过 fetch() + createObjectURL() 动态插入的图，且你已在 img.src 赋值前设好 decoding="async"
• 小图标（16×16）、SVG、头像图（≤200px）加了基本没收益，反而增加 HTML 解析开销

为什么写了 decoding="async" 还卡

不是属性失效，而是被其他行为抵消或掩盖：

• srcset 没配 sizes：浏览器选错高清图，单张体积翻倍，解码压力不降反升
• 没声明 width 和 height（或 aspect-ratio）：解码虽异步，但后续重排导致视觉抖动，比解码卡顿更伤体验
• 父容器用了 overflow: hidden + loading="lazy"：图片永远不进入视口，根本没机会加载和解码
• JS 懒加载库（如 lozad）在滚动时才动态替换 src：覆盖了原生 decoding 设置，禁用 JS 后测试即可验证

decoding 必须配合哪些属性才不白写

它不是独立开关，漏掉任一环，async 就只是个字符串：

html-deploy

使用 htmlcode.fun 将 HTML 内容或文件部署到网页，适用于用户要求“部署到网页”“托管此 HTML”“生成此前端...的实时链接”等场景。

下载

• 必须写在最终渲染的 <img> 上 —— <picture> 或 <source> 上设 decoding 完全无效
• JavaScript 动态创建 img 时，decoding 必须在设置 src 之前赋值，否则 Chrome ≤86 会静默丢弃
• 与 loading="lazy" 并存才有协同价值：前者管加载时机，后者管解码时机，两者叠加才能缓解滚动卡顿
• 框架中（React/Vue）别靠 useEffect 或 mounted 后补属性 —— 此时 DOM 已挂载，必须在元素创建时就注入

sync / async / auto 到底怎么选

别信“默认就是 sync”这种过时认知。现代浏览器（Chrome ≥87、Firefox ≥78、Safari ≥16.4）对未声明 decoding 的 <img>，实际默认走异步路径：

立即学习“前端免费学习笔记（深入）”；

• decoding="auto" 是规范占位符，当前所有主流浏览器都当不存在，别用
• decoding="sync" 仅用于两类场景：需立刻读 img.naturalWidth 参与布局计算；或有帧级同步要求（如 canvas 绘图首帧、动画序列入口图）
• decoding="async" 才是绝大多数非首屏、非关键图的合理选择，但它不是性能银弹 —— 真正难的是让尺寸、格式、加载策略、解码时机四者咬合严丝

真正容易被忽略的点是：你改了 decoding，但没检查最终渲染的 DOM 里是否真有这个属性；或者用了 Webpack/Vite 的 HTML 压缩插件，它默认删掉不认识的属性，得手动配置保留 decoding。