首屏大图必须用<picture>配合media、sizes和loading="eager"协同工作，否则退化为单图加载；需按视口宽度构图级切换、WebP优先、渐进式JPEG+decoding="async"+骨架占位防CLS。
首屏大图必须用 <picture>，但只写标签没用——关键在 media、sizes 和 loading 三者协同，漏一个就退化成单图加载，秒开变卡顿。
为什么首屏大图不能只靠 <img srcset>
浏览器光看到 srcset 不知道这张图在你屏幕上占多宽，会按默认 100vw 猜尺寸，结果手机加载 3840w 图、桌面反而加载 768w 版本。只有 <picture> 配合 media 才能真正按设备视口宽度做构图级切换，不是简单缩放。
-
media="(max-width: 768px)"必须带括号，写成max-width: 768px（缺括号）直接被忽略 - 断点要互斥：用
(max-width: 768px)→(min-width: 769px) and (max-width: 1200px)→(min-width: 1201px)，重叠会导致高分辨率设备永远卡在第一个匹配项 - 首屏图禁用
loading="lazy"—— 即使 DOM 在后面，只要初始渲染时在视口内，就必须设loading="eager"，否则 Chrome 可能延迟 300ms 才发起请求
<source> 的顺序和格式优先级怎么写才生效
浏览器从上到下解析 <source>，遇到第一个「媒体查询匹配 + 格式支持」的就停，后面全跳过。所以 WebP 必须放 JPEG 前面，且 type="image/webp" 对应的响应头必须是 Content-Type: image/webp，否则 Chrome 显示 blocked:mime-type 并静默回退到 <img>。
- 正确顺序：
<source type="image/webp" media="..." srcset="...">→<source type="image/jpeg" media="..." srcset="...">→<img src="fallback.jpg" ...> - 每个
<source>的srcset里用x描述符（如hero@2x.jpg 2x），不用w——w依赖sizes计算，首屏图更推荐确定性更强的x -
<img>的src必须存在，它是所有老浏览器和 JS 禁用环境下的唯一 fallback，空着就留白
首屏大图的性能陷阱：占位、解码、动效怎么配
炫酷大图不是堆分辨率，而是控制加载节奏。骨架占位 + 渐进式 JPEG + decoding="async" 缺一不可，否则哪怕图再小，解码也会阻塞主线程。
立即学习“前端免费学习笔记（深入）”；
- 用纯色背景 + SVG 模糊轮廓做占位，避免布局跳动（CLS）；别用
height: 0; padding-top: 56.25%这类 CSS 占位，懒加载下易闪白 - 服务端必须输出渐进式 JPEG（加
-interlace Plane参数），首帧模糊可快速呈现，用户感知更快 - 给
<img>加decoding="async"，防止解码卡住渲染；fetchpriority="high"只对<img>有效，<source>上写无效 - CSS 动效（如淡入）统一写在
<img>上，别在<source>里重复定义，它不参与渲染
深色模式和无障碍适配不是锦上添花，是首屏图的硬需求
企业官网首屏大图常含品牌 logo 或文字，浅色图在深色模式下可读性崩塌。仅靠 CSS filter: invert() 会糊掉细节，必须准备独立设计的暗色版资源。
- 用
<source media="(prefers-color-scheme: dark)">指向专色优化图，不是调色后导出，是设计师重排版、调对比度、加阴影 - 加
<source media="(prefers-reduced-motion: reduce)">提供静态图版本，否则动效可能触发用户眩晕 -
alt文本必须语义明确：“XX科技总部大楼外立面，玻璃幕墙反射蓝天白云”，不能是 “banner1” 或空字符串
真正让首屏大图“极速”的，不是分辨率数字，而是浏览器能否在 HTML 解析阶段就精准预取、解码不卡主线程、视觉反馈即时可见——这些都藏在 media 括号是否完整、sizes 是否缺失、loading 是否写错 eager 这些细节里。
