软件站做 LCP 优化最常见的浪费，是把首屏最大的那张产品截图当成 LCP 元素，压了半天，其实真正的 LCP 元素是上面那个大标题。先定位元素再动手，三步，十分钟能定下来。
第一步：看实验室里的 LCP 元素
PageSpeed Insights 的诊断区块里有 LCP 元素截图和它的选择器；Chrome DevTools 的 Performance 面板录一段加载，时间轴上会标出 LCP 候选和最终元素。这一步能解决八成站点。
有个坑要注意：如果截图里 LCP 元素是空白，或者显示的是一个 div，多半是图片没下载完就记录了，直接跳到第二步。
第二步：把元素和请求对上
LCP 元素告诉你"是谁"，请求瀑布图告诉你"为什么慢"。两个数必须对得上：
- 元素是图，看那张图的发现时间和下载时间
- 元素是文字，看字体文件加载和阻塞的 CSS
- 元素是容器背景，顺着 CSS 依赖链往下查
我们上周查一个站，LCP 元素是 h1 文字，请求里排第一的却是一张 1.2MB 的 banner。原因不复杂：字体加载晚于图片，h1 一直用回退字体渲染，等字体到位才记录 LCP。这种情况下你压缩 banner 是无效的，要去修字体加载路径。
第三步：用真实用户数据交叉验证
实验室是固定网络、固定设备，真实用户不是。GSC 的 Core Web Vitals 报告和 CrUX 数据能按设备、按国家分组，能看出移动端和桌面端是不是同一个元素。
我们见过移动端 LCP 元素是首图、桌面端是 h1 的站——两个端布局不同，移动端首图占满整屏。这种站只按桌面端优化，移动端等于一点没动。那家客户移动端 P75 是 3.8 秒，桌面端 2.1 秒，差了 1.7 秒，而移动端流量占了他们总访问的 64%。按桌面数据做决策，优化的方向从一开始就是偏的。
常见问题
Q：同一个页面，LCP 元素每次测都不一样怎么办？
先关掉自动轮播、先别加载 AB 测试和个性化推荐。这三个东西都会让首屏内容变来变去，测出来的元素自然不稳定。关掉之后再测三轮，取出现次数最多的那个元素，那才是你该改的目标。
Q：实验室数据和真实用户数据差一倍，信哪个？
都信，但动手术看实验室，验收看真实用户。实验室能告诉你瓶颈在哪，真实用户告诉你改了有没有用。只看实验室容易优化出一个漂亮分数，只看真实用户又不知道从哪里下手。
一个判断标准
三步走完，如果 LCP 元素和那个最慢的请求对不上，先别优化，去查优先级和发现时机；对上了，路径就很清楚：减体积、提前发现、去掉阻塞。
还有一个顺序问题：软件站的首屏经常有轮播图或者动态文案，LCP 元素会来回跳。遇到这种站，先关掉自动轮播再测，别拿一个每次都不一样的结果去做决策。
元析智能
为软件公司做 SEO 和 GEO 优化