<picture> 标签本身不触发预读取，浏览器仅加载最终匹配的 <source> 或兜底 <img>；所谓“预加载”多源于手动 preload、框架注入等外部干预，而非原生行为。

标签本身不触发预读取，浏览器只加载最终匹配的或<img>，其余完全不下载——所谓“预读取”是常见误解。

为什么你看到的“预加载”其实是错觉

很多人在 DevTools 的 Network 面板里发现多张图都进了缓存，就以为 <picture> 在“预读取”。其实那是你手动写了多个 <img>、用了 link rel="preload"，或者框架/构建工具自动注入了预加载逻辑。原生 <picture> 没有预读取机制，浏览器严格按顺序匹配第一个 <source>，命中即止，后面的 srcset 值连解析都不会做。

想让多张图提前进缓存，得自己加 link rel="preload"

• 必须显式声明，且 as="image" 不可省略，否则浏览器不识别为图片资源
• href 要和 <source> 中实际用到的 URL 完全一致（含路径、查询参数、大小写）
• preload 的 media 属性和 <source> 的 media 无关联，它是独立的加载指令
• 例如：<link rel="preload" as="image" href="hero-mobile.jpg" media="(max-width: 768px)"> —— 这行只在匹配时触发 preload，但不会影响 <picture> 内部选择逻辑

<picture> 里混用 loading="lazy" 的真实行为

这个属性只作用于最终兜底的 <img> 元素，对 <source> 无效。也就是说：

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

• 如果当前视口匹配某个 <source>，浏览器加载它，loading="lazy" 被忽略
• 如果不匹配任何 <source>（比如 media 全写错），才 fallback 到 <img>，此时 lazy 才生效
• 别指望靠它“懒加载多个候选图”，那不是它的设计目标

真正影响首屏加载速度的关键点

多数人卡在“以为 picture 能智能预判”，结果写出的结构反而拖慢渲染：

• <source> 顺序错（比如把窄屏规则放后面）→ 匹配失败，降级到 <img src>，而这张图可能又大又没压缩
• sizes 缺失或写死（如 sizes="400px"）→ 浏览器无法估算布局宽度，srcset 中的 x/w 描述符失效，可能选错分辨率版本
• type="image/webp" 对应的服务器响应头不返回 Content-Type: image/webp → 整个 <source> 被跳过，不报错也不警告

记住：<picture> 是声明式选择器，不是预测引擎。它不猜你接下来要缩放窗口，也不管你是否滚动到图片位置——它只在解析 HTML 时做一次判断，然后停手。所有“提前准备”的事，得你亲手用 link preload、CDN 缓存策略、构建时生成多尺寸图来补足。