decoding属性仅控制图片数据获取后的像素解码时机，不影响下载；async仅对≥1000px或≥500kb的大图有效，可避免主线程卡顿，但首屏关键图、小图及未压缩图不应滥用。
decoding 属性只控制图片拿到数据后、在主线程上何时执行像素解码，不是控制下载时机。加了它不等于快了，乱用反而让页面更卡。
decoding="async" 什么时候真有用
只对大图有效：宽 ≥ 1000px 或体积 ≥ 500KB。这类图解码 CPU 开销大，同步执行会卡住滚动、点击等交互。decoding="async" 把解码挪到后台线程，主线程继续渲染和响应事件。
- 适合场景：滚动区域里的商品缩略图、次屏 banner、列表页大量中高分辨率图
- 不适合场景：头像、图标、按钮背景图、未压缩的 PNG/JPEG（网络下载才是瓶颈）
- 首屏关键图别硬套——尤其配合
loading="lazy"时，图还没下载完，异步解码根本没东西可解
decoding="sync" 不是“更稳”的默认选项
decoding="sync" 强制浏览器等解码完成才把图片塞进布局流，会导致明显卡顿，尤其在低端设备上。它只适用于极少数需要像素级同步的边缘场景：
- CSS 背景图 +
background-size: cover且必须严丝合缝撑满容器 - Canvas 绘图前依赖
img.naturalWidth做精确尺寸计算（但更推荐监听load事件） - 动画帧序列中某张图必须和文字渲染节奏完全对齐（现实中几乎不存在）
绝大多数普通 <img> 标签设成 sync，只是让页面多等几十毫秒，毫无收益。
和 loading、fetchpriority 搭配的真实表现
三者混用时，浏览器有明确优先级：下载优先于解码，解码又受带宽和并发限制。
-
fetchpriority="high"+decoding="async"：主图会优先下载，但 4K WebP 解码仍要 80ms+，异步只是不阻塞主线程，不代表解码更快或不挤占其他图资源 - 首屏主图建议只设
fetchpriority="high"，去掉decoding（交给浏览器 auto 决策） - 次屏图可组合
loading="lazy"+decoding="async"，但必须配width/height防 CLS - 超多图列表（如电商瀑布流）：
fetch()+createImageBitmap()手动控并发更可靠，比纯 HTML 属性精细得多
容易被忽略的兼容性与副作用
decoding 在 Safari 15.4+、Chrome 78+、Firefox 69+ 支持，但 Edge ≤18 和部分安卓 WebView 完全忽略。别指望它兜底。
最常被忽视的是副作用：decoding="async" 后，图片可能在解码完成前短暂显示为纯色块或空白，尤其快速滚动时——这不是 bug，是异步解码的固有行为。如果你没声明 width/height，或没用现代格式（WebP/AVIF），或没配 sizes/srcset，那 decoding 就只是个摆设。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
