我们审计过 11 个软件公司官网，其中 8 个的 LCP 元素是首屏那张产品截图，不是文字标题。原因集中在三处：图按设计稿尺寸直接导出、首屏图被统一加了懒加载、首图写在 CSS 背景里。改完这三处，平均能从 4 秒出头压到 2.2 秒左右，不需要动服务器。
原因一：图按设计稿尺寸导出
去年 11 月接的一个项目管理 SaaS，首页 hero 图是 2400×1350 的 PNG，1.8MB，而它在页面上实际只渲染 720 像素宽。设计师给的 2 倍图，前端直接放了原图，没人算过这一张占了首屏流量的七成。
改成 1440 宽、WebP 质量 78，体积 180KB。同一张图，在笔记本上肉眼分辨不出差别。这个站的 LCP 从 4.1 秒降到 2.9 秒，只动了这一处。
查法很简单：Performance 面板里看 LCP 请求的 transfer size，再和 Elements 里这张图的实际渲染尺寸对一下。传输体积超过渲染面积所需的两倍，就是浪费。这个判断不需要工具，手算一下就行。
原因二：首屏图被统一加了懒加载
很多模板给所有 img 统一加 loading="lazy"，图省事。首屏图懒加载的代价是浏览器不会在解析 HTML 阶段就拿它，要等布局算完、判断它进入视口，才开始下载。移动端这一步能拖 300 到 600 毫秒。
我们查过一个开发者工具站，LCP 元素明明是首屏的架构图，Lighthouse 里这个请求的发现时间排在第 9 位。把首屏那张图的 lazy 去掉，它从第 9 位提到第 2 位，LCP 从 3.6 秒到 2.4 秒。
判断标准：首屏内的图不要 lazy，首屏外的图必须 lazy。一个属性的事，值得单独检查一遍。
原因三：首图是 CSS 背景图
background-image 写在样式表里，浏览器要先下载 CSS、解析、匹配选择器，才知道有这么张图。这层依赖让它的发现时间比 HTML 里的 img 晚一个 RTT 以上。
一个安全工具站的首图是背景图，2.4MB。我们把它改成 <img> 加 object-fit: cover，顺手做了响应式尺寸，LCP 从 3.9 秒到 2.6 秒。如果非要用背景图，至少在 HTML 里加 preload，但维护成本更高，不如直接换标签。
先改图，再谈别的
这三处的共同点是：改的是资源本身，不是加载策略。很多团队一上来就研究 CDN、预加载、HTTP/3，方向反了。首图 1.8MB 摆在那儿，CDN 再快也得把这 1.8MB 传完。
顺序应该是：先把图减到该有的体积，再去掉阻碍发现的属性，最后才考虑链路优化。前两步能解决软件站七成的 LCP 问题，剩下三成才是服务端和协议的事。
一个我们常用的取舍
客户经常问，首图到底该放多大。我们的经验值是按容器渲染宽度的 2 倍出图，质量 75 到 80，WebP 优先。超过这个规格，画质提升用户看不出来，体积却线性上涨。遇到一定要放 3 倍图的设计需求，让设计师把纹理和高光做成渐变，比提高分辨率更省。
另一个容易忽略的点是首图的 alt 和尺寸属性。宽高写死能让浏览器提前占位，既避免 CLS，也让 LCP 记录更准。我们见过好几个站，首图没有 width 和 height，布局抖一下，LCP 时间跟着延后 200 毫秒。
最后提醒一句：改完图要清 CDN 缓存，再重新测。我们有一次改完等了两天没效果，最后发现是边缘节点还挂着旧的 1.8MB 版本。
元析智能
为软件公司做 SEO 和 GEO 优化