图片资源管理关键在加载时机、格式选择、尺寸供给和缓存协同：首屏图须用 loading="eager" 或省略该属性；<picture> 回退链需按 WebP→AVIF→JPEG 顺序书写，type 值严格匹配；CDN 应关闭自动格式转换，交由 HTML 层决策；srcset 必须配合准确 sizes（如 "(max-width: 768px) 100vw, 50vw"）才能实现真正响应式加载。
图片资源管理不是“加个 loading="lazy" 就完事了，关键在加载时机、格式选择、尺寸供给和缓存协同这四点上卡得严不严。
为什么 loading="lazy" 有时反而拖慢首屏
浏览器对 loading="lazy" 的处理是延迟到滚动事件触发后才发起请求，但首屏图片如果也加了它，就会错过 DOMContentLoaded 前的最优加载窗口。尤其当首屏含轮播图、Banner 或 LCP 元素时，懒加载直接拉低 Core Web Vitals 分数。
- 只对
offsetTop > window.innerHeight * 1.5的图片设loading="lazy"（即视口下方至少一屏半） - 首屏图片必须显式写
loading="eager"，或干脆不写该属性（默认行为就是 eager） - 服务端渲染（SSR）场景下，需确保 HTML 中首屏
<img>已带完整src，不能依赖 JS 后置替换
<picture> + <source> 回退链怎么写才不掉坑
很多人以为套个 <picture> 就自动兼容，其实顺序错、type 写错、srcset 缺失 fallback，都会导致现代浏览器降级失败，最终加载的是体积更大的 PNG/JPEG。
-
<source>必须放在<img>之前，且按格式支持优先级从高到低排列（WebP → AVIF → JPEG） - 每个
<source>必须有type属性，值严格为"image/webp"或"image/avif"，不能写成"webp" -
<img>的src是最终 fallback，必须存在且指向 JPEG/PNG；若只留srcset没src，老浏览器会不加载任何图
正确示例：
立即学习“前端免费学习笔记（深入）”；
<picture> <source srcset="hero.webp" type="image/webp"> <source srcset="hero.avif" type="image/avif"> <img src="hero.jpg" alt="首页横幅"> </picture>
CDN 图片优化参数要和 HTML 层联动
用 Cloudflare、阿里云 CDN 时开启“自动 WebP 转换”看似省事，但实际会破坏 <picture> 的语义控制：浏览器本该根据 Accept 请求头选格式，结果 CDN 强制返回 WebP，而你 HTML 里 fallback 的 JPEG 根本没机会被用上，还可能因 CDN 缓存策略混乱导致 304 失效。
- 关闭 CDN 的自动格式转换，把格式决策权完全交给 HTML 层（
<source>+type） - CDN 只做两件事：启用 Brotli 压缩、设置
Cache-Control: public, max-age=31536000, immutable（针对带哈希的静态图） - 若需实时裁剪/缩放，用 CDN 提供的 URL 参数（如
?width=800&format=webp），但必须同步更新 HTML 中的srcset值，否则sizes计算会错位
srcset 和 sizes 配合失效的典型原因
写了 srcset 却还是加载了桌面图给手机，大概率是 sizes 没写对，或者媒体查询条件和真实设备宽度不匹配。浏览器靠 sizes 预估元素宽度，再从 srcset 里挑最接近的源，这步算错了，后续全白搭。
-
sizes值必须是媒体条件 + 宽度描述，例如sizes="(max-width: 768px) 100vw, 50vw"，不能只写"100vw" - 如果图片容器用 Flex/Grid 自适应，
sizes应反映其实际占位宽度，而非父容器宽度（比如 flex: 1 的子项在 3 列布局中实际占约 33vw） - Chrome DevTools 的 Network → Img 标签下看 “Size on disk” 和 “Natural size”，两者严重不一致就说明
sizes估计偏差大
真正难的不是语法，是让 sizes 描述和 CSS 布局行为保持同步——改一次 Grid 模板，就得同步调 sizes 值，这点容易被忽略。
