懒加载不是越多越好。今年 1 月我们给一个文档站做首屏优化，把三张首屏图的 loading="lazy" 去掉，LCP 从 2.9 秒降到 2.0 秒。同一个页面，代码只删了三个属性。
首屏一律不用懒加载
原理不复杂：懒加载让浏览器把图片下载推迟到布局计算之后，首屏图本来最该先下载，结果排在最后。移动端这一步的代价是 300 到 600 毫秒。
判断首屏别靠感觉。用 375×667 的视口截图，能看到的都算。注意边界会随设备变化，iPhone SE 和 iPhone 15 Pro Max 差了两屏，我们按最小视口来定"必须立即加载"的范围。
折叠线附近要提前加载
第二类错误是等进了视口才加载。用户往下滚 200 像素图片才开始下载，等待感很明显。
做法是 loading="lazy" 加 IntersectionObserver 的 rootMargin，提前 300 到 500 像素开始加载。这个文档站的侧边目录有 12 张缩略图，原来滚到才加载，滚快了会看到空白。加 400 像素预载后，滚动过程里再没出现空位。
iframe 要单独处理
第三类错误是把视频、地图、客服 iframe 都设成 lazy。副作用是用户点击播放时才开始加载播放器，第一次点击要等 1 到 2 秒，这个延迟会被记进 INP。
做法是首屏 iframe 用 srcdoc 放一个静态封面，点击后再换 src。既省了首屏体积，又不让点击变慢。
和图片 CDN 的配合
用图片 CDN 的站要注意参数别打架。CDN 按 URL 生成不同尺寸，懒加载按视口决定何时请求，两边都配错会出现"小图被放大"或者"下载了 2000 像素宽的图放进 300 像素的框"。
我们的做法是让 CSS 和 HTML 的 sizes 声明对齐，再由 CDN 按 UA 和 DPR 返回合适尺寸。这个文档站改完后，移动端图片平均体积从 180KB 降到 62KB，首屏三张图的请求时间提前了 400 毫秒。
一个反例
我们也见过相反的站：所有图立即加载，一个文档页 40 张截图，首屏请求 6MB。这种站要做的是分页或者折叠，而不是调懒加载参数。真正的浪费不是"懒加载太少"，是"内容一次性全给"。
所以正确用法就三句：首屏立即加载，折叠线下提前加载，非内容型 iframe 延迟到交互。这三句能覆盖九成情况。
怎么验收
改完别只看 Lighthouse 分数，看网络面板里首屏图片的加载顺序和开始时间。首屏图的开始时间应该排在前三个请求里，如果不是，说明有别的东西在抢带宽，先解决抢的那个。
这个站我们改完复查了三次，第一次首屏图还是排在第 6 位，原因是字体 CSS 阻塞了 HTML 解析。把字体改成 preload 之后，顺序才真正提上来。
元析智能
为软件公司做 SEO 和 GEO 优化