decoding属性不加速图片加载，仅改变解码时机；设为async可将CPU密集型解码移出主线程，缓解滚动卡顿，但需图像数据已下载完成才生效。
decoding 属性不加快图片加载，只改解码时机。加对了能缓解滚动卡顿；加错了会让首屏图发虚、延迟渲染，甚至加重主线程阻塞。
decoding="async" 什么时候才真正起作用
它只在图像数据已下载完成、但像素转换（如 JPEG 解码、颜色空间转换）耗 CPU 时生效。不是“让图更快出来”，而是把这一步从主线程挪走。
- 宽 ≥ 1000px 或体积 ≥ 200KB 的 JPEG/WebP/AVIF 图 —— 小图（头像、图标）加了几乎没收益
-
loading="lazy"的图进入视口后触发解码，此时主线程正忙于滚动或动画 - 瀑布流/商品列表中批量出现的缩略图（实测 100+ 张大图滚动时，主线程解码耗时降 40–60%）
- 通过
fetch()+createObjectURL()动态插入的图，且你已在创建img元素后、设src前就赋值decoding="async"
如果控制台看到 Failed to load resource，说明图根本没下完，decoding 压根没机会执行。
sync / async / auto 三个值怎么选才不翻车
现代浏览器（Chrome ≥ 87、Firefox ≥ 78、Safari ≥ 16.4）对未声明 decoding 的 <img>，实际行为默认走异步路径 —— 这和直觉相反。所以“不写 ≠ 同步”，auto 也不是智能切换，而是个占位符，别依赖。
立即学习“前端免费学习笔记（深入）”；
-
decoding="async"：适合非首屏、非焦点区域的大图，如商品列表、评论头像、懒加载图 -
decoding="sync"：仅两类场景必须用 —— 需立即读img.naturalWidth参与布局计算（比如 canvas 贴图尺寸推导），或有严格帧同步要求（如动画序列首帧） -
decoding="auto"：规范默认值，但当前所有主流浏览器都按sync处理 —— 写了等于白写
滥用 sync 会延长主线程占用时间，多张并存时解码排队，首屏渲染反而更慢。
容易被忽略的兼容性与副作用
decoding 必须写在最终渲染的 <img> 上，<picture> 或 <source> 上设无效。Webpack/Vite 构建时若用了 HTML 压缩插件，可能直接删掉这个属性，需显式配置保留。
- Safari 16.4 之前完全不支持，旧版 iOS WebView 会静默忽略（不是报错，是当不存在）
- 某些图像 CDN 或响应式方案中，
decoding必须写在<img>，写在<source>上无效 - Vue/React 中动态渲染时，确保拼写是
decoding，不是decodingAttr或驼峰写法 - JS 懒加载库（如 lozad）在滚动时才动态替换
src，会覆盖原生decoding设置 —— 禁用 JS 后测试一下就清楚
真正难处理的是「既要解码完成又要不卡主线程」的边界场景，比如 canvas 动画首帧 + 首屏大图叠加 —— 这时候得结合 img.decode() API 手动控制，不能只靠属性。
