做速度优化的第一步永远是打开 PageSpeed Insights 看 LCP。十次里有六七次，红色那一行指向的是同一个东西：产品页首屏那张大图。卖家花了大价钱拍的产品图、请设计师做的 banner，效果是好看，但代价是首屏渲染被它拖死了。
常见的第一反应是"上懒加载"，结果 LCP 反而更红了。今天就把这个搭配关系讲清楚。
先搞清楚你的 LCP 卡在哪张图
别猜，直接看数据。PageSpeed Insights 或者 Search Console 的 Core Web Vitals 报告里，LCP 元素会明确列出来——多数产品页就是首图，有时候是 banner 视频poster，偶尔是首屏那块大标题的背景图。确认了元素，才谈得上优化。
这里有个容易踩的坑：测试环境跑分和真实用户数据（CrUX）经常对不上。我们给客户调站时一般以真实用户数据为准，实验室数据只用来验证改动效果。
懒加载是给"首屏之外"用的，首图千万别懒加载
懒加载（loading="lazy"）的本意是"看不到的不加载"，但浏览器判断"是否在首屏"并不总准。一旦首图被误判，它就会等到布局稳定、甚至用户滚动时才开始加载——这等于亲手把 LCP 往后推。
所以规则很简单：
- 首屏的 LCP 元素（通常是首图）：绝对不要加 loading="lazy"，并且显式加
fetchpriority="high"； - 首屏以下所有图片、评论区的用户头像、推荐商品列表：统统懒加载。
一个更隐蔽的问题：有些主题和懒加载插件是"一刀切"的，全站图片都套 lazy。装了这类插件的站点，如果 LCP 变差了，第一件事就是检查插件有没有排除首屏的选项。
首图预加载的正确姿势
确认首图后，在页面 head 里给它加预加载：
<link rel="preload" as="image" href="hero.webp" fetchpriority="high">
这样浏览器解析 HTML 的同时就开始下首图，不用等 CSS 解析完、布局算完才发现"哦，原来这里还有张大图要下"。移动端再配合 srcset 给小屏设备派小尺寸版本，效果立竿见影。我们实测过一个家具类站点，光这一套组合，移动端 LCP 从 4.1 秒降到 2.3 秒，没动一行业务代码。
图片本身也要瘦下来
预加载只解决"什么时候开始下"，图片本身的体积决定了"要下多久"。三个动作按顺序做：
1. 转 WebP 或 AVIF，同画质下体积通常能砍一半以上；
2. 尺寸别虚标，移动端展示 400px 宽的图别发 2000px 的原图，按展示尺寸的 1.5~2 倍出图就够；
3. 走 CDN，主要市场在欧美就选欧美节点为主的服务商，物理距离省不掉。
这几项做完，再把 LCP 目标定在 2.5 秒以内就现实了。Core Web Vitals 的另外两项指标怎么一起看，可以参考这篇Core Web Vitals 优化指南；整体加载时间的优化思路，之前也写过一篇页面加载时间优化，配合着看。
一句话总结：懒加载管"首屏之外"，预加载和高优先级管"首屏那一张"，再加上图片瘦身——三件事各管各的，别互相抢活。