<picture>元素本身不提供渐进式加载，它只做声明式资源选择；高清大图的渐进式响应加载优化是格式回退、尺寸适配与渲染预留三者组合落地的结果，核心目标是小屏不载大图、高密度屏不降质、布局不跳动、旧浏览器有兜底。

元素本身不提供“渐进式加载”，它只做声明式资源选择。所谓高清大图的渐进式响应加载优化，其实是把**格式回退 + 尺寸适配 + 渲染预留**三者组合落地的结果，核心目标是：小屏不载大图、高密度屏不降质、布局不跳动、旧浏览器有兜底。

按设备能力分层加载：先格式，再尺寸

浏览器对是顺序匹配、一命中即停止，所以要把兼容性最差但压缩率最高的格式放在最上面，尺寸适配逻辑放下面——避免高支持度浏览器因格式匹配成功而跳过后续尺寸判断。

推荐结构（兼顾现代格式与多断点）：

• 第一层用type="image/avif"：AVIF体积最小，适合宽带环境；若浏览器不支持，自动跳过
• 第二层用type="image/webp"：WebP兼容性更广（Chrome/Firefox/Safari 14+），仍不支持则继续向下
• 第三层用media + srcset + sizes：针对不同视口宽度提供3–4个真实CSS断点对应的图片，比如768w、1200w、1920w
• 最后必须带src、alt、width和height：这是所有fallback的最终出口，缺一不可

sizes 属性要真实反映 CSS 占位宽度

告诉浏览器“我有哪些图”，才告诉它“你该在什么宽度下选哪张”。如果没写sizes，浏览器默认按100vw估算，哪怕你的图片只占300px宽，也可能拉下1920w的图。

实操要点：

HTML Extract

使用 MinerU 从 HTML 页面和文件中提取内容，将 HTML 转换为保持标题、列表、表格及文本层次结构的干净、结构化 Markdown。F...

下载

• 查你在各断点下图片容器的真实渲染宽度（DevTools → Elements → Computed → width）
• 按实际值写sizes，例如：sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw"
• 避免写死sizes="100vw"，除非是全屏横幅图

防 layout shift：必须预设图片占位空间

内部的若没设width/height，或设为auto，浏览器无法预留空间，图片加载完成瞬间触发重排，用户感知就是“闪一下”——这不是网络慢，是渲染阻塞。

稳妥做法：

• 用内联width和height属性，值取原始图宽高比（如800×450），不是响应式尺寸
• 配合CSS aspect-ratio: 16/9（Safari 15.4+支持），老版本可用padding-top技巧降级
• 别依赖object-fit: cover来“掩盖”尺寸未定义问题，它不影响占位计算

验证是否真优化了：用 DevTools 看请求实效

优化不是靠猜。打开 Chrome DevTools → Network，勾选“Disable cache”，硬刷新几次，观察：

• 哪些请求根本没发出？那就是冗余的srcset项，删掉
• 首屏图片是否加载了对应设备的合理尺寸？比如iPhone竖屏应是375w或414w档，而非1200w
• WebP/AVIF是否被实际使用？查看Response Headers里的Content-Type
• 检查Elements里img节点的computed width/height是否稳定，无抖动

不复杂但容易忽略。