单纯加 loading="lazy" 不能解决响应式图片加载慢，因其只控制加载时机，不解决选图逻辑；必须配合 srcset 和 sizes 才能精准加载适配尺寸的图片。
单纯加 loading="lazy" 不能解决响应式图片加载慢——它只控制“什么时候加载”，不解决“加载哪张图”。很多页面加了 lazy 后仍卡顿，是因为浏览器在移动端误下了 1920w 的大图。
为什么 loading="lazy" 单独用效果差
原生懒加载只推迟请求发起时间，但 srcset 选图逻辑完全独立。如果没配 sizes，浏览器默认按 100vw 计算，哪怕你的图片 CSS 宽度只有 300px，它也可能拉一张 1200w 的图下来。结果就是：延迟加载了，但加载的还是错的图。
- 移动端用户看到首屏后滚动，突然触发一堆
1200w.jpg请求，带宽和解码压力集中爆发 -
loading="lazy"对background-image完全无效，这类写法必须重构为<img> - 服务端未开启 WebP/AVIF 支持时，
<picture>回退失败，最终全走src的 JPEG，体积翻倍
srcset + sizes + loading="lazy" 必须三者齐备
三者是协同关系，缺一不可：
-
srcset告诉浏览器“我有哪些图”（如"cat-400.jpg 400w, cat-800.jpg 800w"） -
sizes告诉浏览器“你在当前断点下该占多宽”（如"(max-width: 480px) 100vw, (max-width: 768px) 50vw, 33vw"），浏览器据此从srcset中选最匹配的源 -
loading="lazy"在上一步选图完成后，再决定“这张图要不要现在发请求”
错误示例：<img src="fallback.jpg" srcset="big.jpg 1200w" loading="lazy"> —— 没 sizes，浏览器只能猜，大概率选错；正确写法应包含完整三元组。
立即学习“前端免费学习笔记（深入）”；
首屏图必须排除懒加载，且优先用 WebP
banner、主视觉图等首屏关键图片，加 loading="lazy" 是反模式。它们需要立即加载，但必须最小化体积：
- 禁用
loading="lazy"，或显式写loading="eager" - 用
<picture>提供 WebP 主力 + JPEG 兜底，例如：<picture> <source type="image/webp" srcset="hero-800.webp 800w, hero-1200.webp 1200w" sizes="(max-width: 768px) 100vw, 1200px"> <img src="hero-1200.jpg" srcset="hero-800.jpg 800w, hero-1200.jpg 1200w" sizes="(max-width: 768px) 100vw, 1200px" alt="Hero"> </picture>
- 所有
<img>必须带width和height属性（如width="1200" height="400"），否则 layout shift 会让“加载完成”感知变慢
CDN 和服务端配置不当会让前端努力白费
即使 HTML 写得完全正确，以下服务端问题会导致 srcset 或格式回退失效：
- Nginx/Apache 未配置
image/webp和image/avifMIME 类型，浏览器收到text/plain就直接拒收 - CDN 缓存策略对不同
srcsetURL 做了统一缓存（比如把cat-400.jpg和cat-1200.jpg都缓存在同一个 key 下），导致小图被大图覆盖 - 未启用 Client Hints（
DPR,Width），浏览器无法向服务端传递设备能力，后端无法做动态图片裁剪或格式协商
最容易被忽略的是：你改完了 HTML，但 CDN 缓存没清，或者服务端返回的 Content-Type 错了——这时打开 DevTools Network 标签页，看图片响应头里的 content-type 和状态码，比反复调前端代码更直接。
