decoding="async"不一定让页面更流畅，仅对宽≥1000px或体积≥500kb的大图有效，可将解码移至后台线程缓解主线程阻塞；小图、未压缩图、首屏关键图滥用反而损害性能，需配合尺寸声明、现代格式与合理加载策略才能真正提升感知性能。
decoding="async" 真的能让页面更流畅吗？
不一定。它只在特定条件下缓解主线程阻塞，不是“加了就变快”的万能开关。关键看图片尺寸、格式、设备性能和上下文——对小图或未压缩图硬套 decoding="async"，反而可能因解析开销增加而引发短暂闪烁或解码延迟。
哪些图片适合加 decoding="async"
仅对真正消耗 CPU 的大图有效，浏览器才有动力挪到后台线程解码。其他情况基本白加。
- 宽 ≥ 1000px 或体积 ≥ 500KB 的 JPEG/PNG（WebP/AVIF 通常自带高效解码，收益更小）
- 非首屏、非关键路径的图片：商品列表图、文章配图、评论头像墙等
- 配合
loading="lazy"使用时，必须确保图片已进入加载队列（即懒加载已触发），否则下载还没开始，异步解码无从谈起
decoding="async" 和 loading="lazy" 能一起用吗？
能，但组合效果受限，且容易误判收益。它们解决的是不同阶段的问题：一个管“什么时候下载”，一个管“什么时候解码”。如果图片本身体积大、格式老旧、又没声明 width/height，即使两个属性都加了，仍可能因布局偏移（CLS）或解码排队导致视觉卡顿。
- 必须配
width和height属性，否则浏览器无法预留空间，decoding="async"无法防止重排 - 避免和
fetchpriority="high"同时用于非首屏图——高优下载 + 异步解码 ≠ 更快呈现，反而可能挤占其他资源的解码带宽 - 在
<picture></picture>中，decoding必须写在最外层<img>上，<source></source>上无效
为什么有时候加了 decoding="async" 还是卡？
因为解码只是瓶颈之一。真正拖慢感知流畅度的，往往是三件事没做：没提前声明尺寸、没选现代格式、没控制加载时机。单独调一个属性，就像只拧松一个螺丝去修发动机。
- 没设
width/height→ 解码完成前无法确定布局，触发 CLS，用户感觉“跳” - 用的是未压缩 PNG 或巨幅 JPEG → 即使异步，解码本身也要 60–120ms，低端安卓机可能超 200ms
- 大量
decoding="async"图片集中触发（比如瀑布流滚动到底部）→ 后台解码线程饱和，实际变成串行解码 - Safari 15.4 以下、旧版 WebView 完全忽略该属性，你写的它当没看见
真正难处理的，是既要像素稳定又要不卡主线程的边界场景——比如 canvas 动画首帧叠加一张 2MB 主图。这时候靠属性已经不够，得用 img.decode() 手动调度，而不是寄希望于 decoding="async" 自动兜底。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
