本身不优化首屏，仅做条件资源选择；若用法不当（如src兜底图过大、缺sizes、type不匹配），会导致重复加载或选错资源，反而拖慢首屏。
为什么 <picture></picture> 对首屏没用，甚至拖慢加载
直接上结论：<picture></picture> 本身不优化首屏，它只做“条件性资源选择”，不改变资源是否被浏览器提前发现、是否参与关键渲染路径。如果用法不当，反而会让首屏更慢——比如把高分辨率 srcset 图片放在 <source></source> 里，而 <img> 的 src 指向一张大图，浏览器会同时预加载两者。
常见错误现象：
– Lighthouse 报 “Avoid enormous network payloads”
– 首屏图片加载延迟，尤其在 3G 模拟下明显卡顿
– DevTools 的 Network 面板看到多个图片请求并行发起，但只有一张被实际渲染
- 必须确保
<img>的src属性指向**最小可用尺寸的 fallback 图**（如 400w 或 viewport 宽度内最大可能宽度），而不是“高清图” -
<source></source>中的media和srcset要严格匹配设备能力，避免兜底逻辑失效（例如media="(min-width: 768px)"却没提供max-width: 767px的 source） - 不要在
<picture></picture>里塞 WebP/AVIF 备用格式却不配type，否则低版本浏览器会跳过所有<source></source>，退化到<img src>，而你可能忘了给src设小图
怎么写才能让浏览器尽早发现正确图片
核心是让 <img> 的 src 可被 HTML 解析器同步提取，且尺寸合理；<source></source> 则用于锦上添花，不是主加载通道。
-
<img>的src必须存在，且应为当前视口最可能匹配的尺寸（例如移动端首屏 banner，src用 400w 的 JPG；桌面端则可用 800w） -
<source></source>的srcset值建议用w描述符（如"banner-400w.jpg 400w, banner-800w.jpg 800w"），而非x，这样浏览器能结合sizes属性做准确预估 - 务必加
sizes属性，哪怕只是sizes="100vw"；否则浏览器按默认 100vw + 1x 计算，可能选错资源 - WebP/AVIF 等格式必须显式声明
type="image/webp"，否则会被忽略，且不能依赖 JS 检测后动态插入 —— 那样就彻底失去预加载优势
遇到 loading="lazy" 时的陷阱
首屏图片绝不能加 loading="lazy"，但很多人会无意识继承全局规则或 CMS 模板配置。更隐蔽的问题是：即使没写 lazy，<picture></picture> 里的 <source></source> 不触发预加载，只有 <img> 的 src 才会。
- 检查渲染前的 HTML 源码，确认首屏
<img>标签没有loading="lazy"—— 不要依赖 CSS 或 JS 后续移除 - 如果使用构建工具（如 Webpack/Vite）自动注入
loading="lazy"，需配置排除首屏区域（如 class="hero-img"） -
<source></source>标签无论是否在首屏，都不会触发预加载；它的作用仅限于<img>渲染时的源选择，不是独立资源加载指令
验证是否真起效：看 Network 和 Coverage
别信代码写得“看起来对”，要看浏览器实际行为。重点不是有没有用 <picture></picture>，而是首屏是否只加载了那张该加载的图。
- 在 Chrome DevTools 中禁用缓存，硬刷新（Ctrl+Shift+R），切到 Network 面板，过滤
Img，观察首屏图片是否只有一个请求，且尺寸符合预期 - 打开 Coverage 面板（More Tools → Coverage），重载页面，查看 HTML 文件中哪些
<source></source>行被标记为未使用（浅灰）—— 如果首屏的<source></source>全是灰色，说明浏览器根本没选它，问题出在media/sizes匹配逻辑 - 用
chrome://net-internals/#events查看URL_REQUEST_DELEGATE类型事件，确认src请求是否在 HTML 解析早期就已发出（start time
真正影响首屏的是 <img src> 的取值时机和大小，<picture></picture> 只是让它更精准。写得越“全”，越容易因 fallback 失控而变慢。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
