<picture>本身不提升速度，但通过<source>匹配条件（media/type）让浏览器仅下载当前设备所需图片，配合<img>显式宽高和loading="eager"，才能真正优化LCP。
为什么 <picture> 不能“自动变快”
浏览器解析 <picture> 的开销几乎为零，它不是性能魔法。真正起作用的是：它让浏览器**只下载当前设备最需要的那一张图**。如果首页大图在手机上仍加载 2560×800 的桌面图，带宽浪费、解码耗时、LCP 延迟就全来了。而 <picture> 提供了精确控制入口，但必须靠 <source> 的 media 或 type 触发匹配逻辑。
- 没写
<source media="...">或<source type="image/webp">→ 浏览器忽略所有<source>，直接 fallback 到内部<img>，白配 -
<img>没设width和height属性（HTML 属性，非 CSS）→ Safari 不预留空间，图片加载后触发重排，LCP 推迟 + 视觉跳动 - 首屏大图加了
loading="lazy"→ 部分 Chrome 版本会延迟加载，导致首屏空白或 FOUC
<picture> 必须配合的三项硬性配置
少了任意一项，响应式图片就退化成普通 <img>，还多了一层 DOM 节点开销。
-
<source>至少带一个匹配条件：media（如media="(max-width: 768px)"）或type（如type="image/webp"） - 兜底
<img>必须有src、alt，且显式声明width和height（例如width="1200" height="400"） - 若需适配高 DPR 设备，
<img>的srcset要配sizes，例如sizes="(max-width: 768px) 100vw, 1200px"
首屏大图用 <picture> 的典型错误组合
企业官网首页轮播图、电商 banner 这类 LCP 元素，最容易因配置失当放大性能问题。
- 写了
<source media="(max-width: 768px)" srcset="hero-m.jpg">，但没给<img>设width/height→ 手机端加载前高度为 0，加载后突然撑开，内容下移 - 用
<picture>提供 WebP，但没测旧版 Safari → 它不支持type="image/webp"，fallback 失败，图片不显示 - 把所有图片（包括 20×20 的 icon）都套
<picture>→ HTML 体积增加、解析时间微升，无实际收益
比 <picture> 更关键的首屏控制点
很多人盯着标签写法，却忽略了更底层的加载节奏。真正卡住首屏的，往往不是“用了什么标签”，而是“什么时候开始加载”。
立即学习“前端免费学习笔记（深入）”；
- 首屏图片必须用
loading="eager"（显式声明），不能依赖默认行为；loading="lazy"在部分安卓 WebView 中对首屏图有延迟 -
<picture>外层不要套<div>再设display: contents等 hack —— 这类样式会让浏览器无法提前计算尺寸，破坏预解析 - 服务端若做 SSR，确保首屏
<picture>的<source>和<img>是静态可推导的，避免 JS 运行后才注入，否则预加载失效
<picture>，是让每个 <source> 都被命中、每张 <img> 都有确定尺寸、每个首屏图都在 TTFB 后立刻发起请求——这些细节一旦漏掉，标签再语义化也救不了 LCP。
