能，但只对非首屏图片生效；浏览器忽略首屏img的loading="lazy"，仅推迟滚动后可见图片的解析与请求，节省带宽和解码开销。
img 标签加 loading="lazy" 真的能提速吗？
能，但只对「非首屏图片」生效。浏览器会忽略首屏内 <img alt="HTML懒加载如何优化首屏速度_HTML懒加载与首屏速度关系【干货】" > 的 loading="lazy"，强制立即加载——这是规范行为，不是 bug。所以别指望它压缩首屏资源体积或减少初始请求量。
真正起效的场景是：长列表、图文流、底部轮播图等用户需要滚动才看到的内容。这时浏览器会推迟解析和请求这些图片，节省带宽与解码开销。
- Chrome 76+、Firefox 75+、Safari 15.4+ 原生支持，无需 JS 库
- 不支持时（如旧版 Safari），
loading属性被静默忽略，不影响渲染 - 慎用于
<picture></picture>内的<source></source>：部分浏览器不识别其loading，建议统一写在<img alt="HTML懒加载如何优化首屏速度_HTML懒加载与首屏速度关系【干货】" >上
IntersectionObserver 手动懒加载更可控，但要注意触发时机
原生 loading="lazy" 触发阈值固定（约视口外 1250px），而用 IntersectionObserver 可自定义进入范围，比如提前 300px 加载，避免滚动时白屏闪烁。
关键点在于 observer 实例复用与回调节流：
立即学习“前端免费学习笔记（深入）”；
- 不要为每张图新建
IntersectionObserver，共用一个实例 +observe()多个<img alt="HTML懒加载如何优化首屏速度_HTML懒加载与首屏速度关系【干货】" > - 回调中立刻调用
unobserve()，防止重复触发；再把src或srcset赋值给 DOM - 避免在回调里直接操作
style或触发布局（如offsetHeight），否则引发强制同步布局
示例片段：
const io = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
const img = entry.target;
img.src = img.dataset.src;
io.unobserve(img);
}
});
}, { rootMargin: '300px' });
懒加载后图片尺寸塌陷导致 CLS（累积布局偏移）
没设宽高的 <img alt="HTML懒加载如何优化首屏速度_HTML懒加载与首屏速度关系【干货】" > 在懒加载完成前高度为 0，加载后突然撑开，页面内容下移——这直接拉高 CLS 分数，影响 Core Web Vitals。
必须提前预留空间：
- 显式设置
width和height属性（注意：不是 CSS，是 HTML 属性），浏览器可据此计算宽高比并预留区域 - 响应式场景下用
aspect-ratioCSS 属性（Chrome 88+）配合width: 100%，兼容性差时回退到 padding-top 百分比 hack - 避免用
object-fit: cover替代尺寸声明——它不解决占位问题
第三方图片服务（如 Cloudinary、Imgix）配合懒加载的坑
这类服务常依赖 URL 参数动态裁剪，但若在 IntersectionObserver 回调里拼接 URL，容易因参数错误或缓存策略导致加载失败或尺寸错乱。
- 确保
data-src存的是完整、可直取的 URL，而非模板字符串（如https://.../w_300,q_auto/xxx.jpg） - 如果要用客户端动态生成 URL，请验证 DPR（
window.devicePixelRatio）和容器宽度是否已就绪，否则可能生成过小尺寸图 - CDN 缓存头需包含
Cache-Control: public, max-age=31536000，否则每次懒加载都走回源，反而拖慢
懒加载本身不解决图片格式、压缩率、CDN 路径这些问题，它只是调度时机。真正卡顿往往出在图片体积过大或未启用现代格式（WebP/AVIF），而不是“要不要懒”。
