picture降级写错会拉低LCP，因浏览器从上到下匹配source，若type错误（如image/jpg）、顺序颠倒或media重叠，将跳过所有source退至img，引发额外解析延迟和请求；同时Chrome对picture预加载支持有限，无法跨source生效。
picture + source 降级本身不提升首开速度，反而可能拖慢——除非你用对了顺序、配对了格式、且兜底正确。
为什么picture降级写错会拉低LCP
浏览器解析 picture 是从上到下逐个匹配 source，一旦某条 source 的 type 或 media 被支持，就立刻发起请求，跳过后续；但如果你把 WebP/AVIF 放在最后，而前面写了不支持的格式（比如 type="image/jpg" 这种错误 MIME），浏览器可能跳过所有 source，退回到最底部的 img，导致多一次解析延迟 + 多一次网络请求。
- 常见错误：
<source type="image/jpg" srcset="hero.jpg">——jpg不是合法 MIME，应为image/jpeg - 更隐蔽的坑：多个
source的media条件重叠或遗漏断点，导致桌面端加载了移动端图，体积翻倍，直接拖垮 LCP - 关键限制：Chrome 对
picture的预加载支持有限，rel="preload"无法跨source生效，只能对最终选中的img[src]预加载
srcset + sizes 比 picture 更适合首屏提速
对纯尺寸适配（如不同屏幕宽度下加载不同分辨率的同一格式图），srcset + sizes 更轻量、解析更快、预加载兼容性更好。它不涉及 MIME 判断，浏览器能更早锁定资源 URL 并发起高优请求。
- 必须同时写
sizes，否则浏览器按设备像素比瞎猜，大概率下错大图 - 安全写法示例：
sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw" -
srcset中的宽度描述符（如800w）必须和原图真实宽度一致，否则切换逻辑失效，可能让 4K 屏加载 400w 图再强行拉伸
WebP/AVIF 降级必须有且仅有一个 img 兜底
picture 的语义是“提供多种源，选一个”，所以浏览器只加载并渲染其中一条路径。如果所有 source 都失败（格式不支持、路径 404、MIME 错误），最终依赖的是 img 标签的 src —— 它不能省，也不能写成空值或占位符。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 错误写法：
<picture><source type="image/webp" srcset="hero.webp"></picture>—— 缺少img，降级失败时页面留白 - 正确写法：
<picture><source type="image/webp" srcset="hero.webp"><img src="hero.jpg" alt="首页横幅"></picture> - 注意：
src只能出现在img上，source的srcset或src属性无效
首屏图别依赖降级，直接预加载 WebP/AVIF
真正影响首开的是“哪张图被浏览器最早拿到”。如果你的首屏 banner 已确定支持 WebP，就不要靠 picture 降级来兜底，而是用 <link rel="preload" as="image" href="hero.webp"> 提前触发下载——前提是 as="image" 写对、href 是静态字符串、且标签放在 <head> 最前面。
- 预加载只对 1–2 张首屏核心图有效，加多了反而挤占带宽
- 如果 fallback 图（如
hero.jpg）才是 LCP 元素，那预加载hero.webp就毫无意义，甚至因 404 增加失败请求 - 验证是否生效：打开 Chrome DevTools → Network → 找该图片 → 查看 “Priority” 是否为 “High”，且发起时间是否早于 HTML 解析完成
降级不是性能优化的起点，而是兼容性收口。真正提速的关键，在于明确知道哪张图卡着 LCP，然后用最短链路把它塞进浏览器管道——格式选对、路径写死、预加载到位、兜底可靠。其他都是干扰项。
