首屏大图必须使用 decoding="sync"，因其需像素就绪才渲染以避免白屏、发虚或延迟；async 会导致解码未完成即渲染，加剧 LCP 延迟与 CLS 风险。
首屏大图不能加 decoding="async"，加了反而可能发虚、延迟渲染甚至白屏。
为什么首屏大图禁用 decoding="async"
首屏大图（如 banner、主视觉图）的核心诉求是「立刻可见、不跳、不闪」。decoding="async" 会把解码扔到后台线程，主线程不等它完成就继续渲染——但此时图片像素数据还没准备好，浏览器只能画空白、占位色或模糊 fallback，用户看到的就是短暂空白或低质量预览。
- Chrome/Firefox 对
decoding="async"的实现是「解码完成前不触发 paint」，不是「先画个 placeholder 再换高清」 - 首屏图通常已预加载或内联，
loading="eager"是默认行为，decoding="async"不仅无收益，还主动放弃同步保障 - 实测中，首屏 WebP 大图（2MB+）设
decoding="async"后，LCP（最大内容绘制）延迟增加 120–300ms，CLS（布局偏移）风险上升
decoding="sync" 是首屏大图的合理选择
这不是“保守”，而是明确告诉浏览器：这张图必须像素就绪才允许渲染。现代浏览器（Chrome ≥ 87、Firefox ≥ 78、Safari ≥ 16.4）对未声明 decoding 的 <img> 实际按 sync 处理，但显式写出来更可靠、可维护。
- 必须配合
width和height（或aspect-ratio），否则即使解码同步，也会因重排导致视觉跳动 - 避免在
<picture>的<source>上写decoding—— 它只在最终渲染的<img>上生效 - 如果用了 CDN 或响应式图片服务（如 Cloudinary、Imgix），确认其生成的 HTML 中
<img>标签确实带decoding="sync"，而非被自动过滤
真正影响首屏大图体验的，是比 decoding 更底层的三件事
decoding 只管解码时机，而首屏大图的卡顿/白屏/模糊，90% 出在它之前：
立即学习“前端免费学习笔记（深入）”；
- 没用
WebP或AVIF格式：JPEG 解码 CPU 开销高，sync也扛不住；同质量下 WebP 体积小 35%，AVIF 小 50% -
srcset没配sizes：浏览器误选 3840w 版本塞进手机屏幕，下载+解码双倍压力 - 缺少渐进式加载能力：没开
-interlace Plane（ImageMagick）或没启用progressive（sharp），首帧无法快速模糊呈现
别在首屏大图上纠结 async 和 auto——它们不是为这种场景设计的。decoding 的价值，在于精准控制「非首屏、大批量、可容忍轻微延迟」的图片行为。首屏图要的是确定性，不是异步自由。
