decoding="async"仅适用于宽≥1000px或体积≥200KB的大图、懒加载图、瀑布流缩略图及fetch动态插入图，需配合loading="lazy"、显式宽高和现代图片格式才有效。
decoding="async"适合哪些图片
它不是给所有图片加就有效的，只对解码耗时明显、又不参与首屏关键渲染的图起作用。加错了反而让 banner 图发虚或延迟出现。
- 宽 ≥ 1000px 或体积 ≥ 200KB 的 JPEG/WebP/AVIF 图（小图如头像、图标加了几乎没收益）
-
loading="lazy"的图片——进入视口后触发解码，此时主线程正忙于滚动或动画 - 瀑布流、商品列表中批量出现的缩略图（实测 100+ 张大图滚动时，主线程解码耗时降 40–60%）
- 通过
fetch()+createObjectURL()动态插入的图，且你已提前设好decoding="async"
注意：如果图片还没下载完（比如控制台看到 Failed to load resource），decoding 压根没机会执行。
decoding="sync"什么时候必须用
它不是“让图更快显示”，而是强制像素数据在渲染前就绪，会阻塞主线程。绝大多数场景不该用，用了反而拉垮 LCP 和滚动流畅度。
- 需要立即读取
img.naturalWidth或img.naturalHeight参与布局计算（比如动态生成 canvas 贴图、CSS Grid 容器尺寸依赖） - 图片作为 UI 基础元素且有严格帧同步要求（如动画序列帧第一帧、实时滤镜入口图），否则可能因解码延迟导致视觉撕裂
- Canvas 绘图前必须确保解码完成：应监听
img.decode()Promise，而不是靠decoding="sync"硬扛
decoding="sync" 不等于 img.complete === true —— 后者只代表加载完成，不代表像素已解码可用。
立即学习“前端免费学习笔记（深入）”；
为什么写了 decoding="async" 还卡
不是属性失效，而是被其他行为覆盖或抵消。常见原因包括：
-
srcset没配sizes，浏览器选错高清图，体积翻倍，解码压力反而更大 - 父容器用了
overflow: hidden+loading="lazy"，图片永远不进入视口，加载都不触发 - JS 懒加载库在滚动时才动态替换
src，覆盖了原生decoding设置（禁用 JS 后测试一下就清楚） - 没设
width/height或aspect-ratio，解码虽异步，但后续绘制频繁重排，Chrome DevTools 的 Rendering > Paint flashing 会大面积闪红
decoding 必须作用于最终渲染的 <img> 元素——<picture> 和 <source> 上设该属性会被完全忽略。
兼容性和构建工具容易忽略的点
这个属性在 Safari 16.4 之前完全不支持，旧版 iOS WebView 会静默忽略——不是报错，而是当不存在。更隐蔽的问题是：
- Webpack/Vite 构建时若用了 HTML 插件自动压缩，可能删掉未知属性，需配置保留
decoding - Vue/React 中动态渲染
<img>时，确保属性名拼写正确（不是decodingAttr或驼峰写法） - JavaScript 动态创建
img时，decoding必须在设置src之前赋值，否则旧版 Chrome 会静默丢弃 - 框架组件（如
next/image）通常已内置解码优化，手动加decoding="async"可能被覆盖，需检查最终生成的 DOM 确认是否生效
真正起效的关键点，往往藏在那行不起眼的 decoding="async" 里；而最容易被忽略的，是它和 loading="lazy"、显式宽高、现代图片格式这三者的协同关系——漏掉任一环，async 就只是个没用的字符串。
