首屏大图必须使用 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 处理，但显式写出来更可靠、可维护。

Markdown to HTML

{"answer":"将 Markdown 转换为内嵌 CSS、样式精美的独立 HTML。完美适用于新闻简报、文档、报告及邮件模板。"}

下载

• 必须配合 width 和 height（或 aspect-ratio），否则即使解码同步，也会因重排导致视觉跳动
• 避免在 <picture></picture> 的 <source></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 的价值，在于精准控制「非首屏、大批量、可容忍轻微延迟」的图片行为。首屏图要的是确定性，不是异步自由。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！