4 秒的 LCP 会对你的结账转化率做什么
四秒钟听起来不长。但在结账页，它就是成交和弃购之间的距离。
顾客已经决定下单了。他把商品放进购物车，从钱包里掏出银行卡，点了结算。然后呢，他盯着一个几乎空白的屏幕，整整四秒。
这四秒就是你的 Largest Contentful Paint。它衡量页面上最大的可见元素出现所需的时间。在结账页，那通常是订单摘要或支付按钮。元素没画出来，顾客就无事可做。只能干等，然后开始怀疑。
怀疑才是真正的麻烦。慢的 LCP 卡住的不只是页面。它卡住的是一个本已做出的购买决定。
你该记住的那个数字
Google 把 LCP 分成三档。2.5 秒以内算好。2.5 到 4 秒之间需要改进。超过 4 秒就算差。你那个跑到 4 秒的结账页，正好踩在这条分界线最糟的一侧。
这不是面子问题。Google 自己公布过：当加载时间从 1 秒涨到 3 秒，用户离开页面的概率上升 32%。从 1 秒涨到 5 秒，上升 90%。你的结账页恰恰活在这个高风险区间。
Akamai 在 2017 年的一份在线零售研究里测到，仅仅 100 毫秒的延迟就能让转化率下降 7%。一百毫秒。而你多花了整整四千毫秒。
为什么结账页是最不该慢的地方
列表页慢和结账页慢，是两回事。在列表页，顾客还在逛。意图还很模糊，所以耐心更多。
到了结账页，意图拉满，耐心见底。顾客已经在心里做完了花钱的决定。每多等一秒，就给犹豫开了一扇窗。他想起自己其实并不真的需要这东西。他盘算着去别处比个价。他收到一条通知，然后离开了。
你丢的不是一个好奇的访客。你丢的是一笔已经到手的生意。
通常是什么在吃掉你这 4 秒
在大多数慢吞吞的结账页里，元凶并不神秘。它很好预测。看看这个常见的套路:
- 阻塞渲染的第三方脚本——聊天插件、再营销像素、在页面顶部同步加载的标签管理器。
- 没有设定尺寸、没用现代格式(AVIF 或 WebP)、也没有正确做懒加载的商品图，逼着浏览器干等。
- 服务器响应慢——Time to First Byte 偏高，因为页面是按需即时生成、没有缓存，而不是预渲染好直接送出。
- 在下载完成前会挡住文字的 web 字体，让支付按钮隐身的时间比应有的更长。
- 过多的 JavaScript，必须先下载、解析、执行完，页面才变得能用。
注意一个关键细节。这些问题几乎没有一个跟页面的视觉设计有关。它们都是工程决策。这就是为什么很多人砸钱重新设计结账页，转化率却纹丝不动。问题从来就不在按钮的颜色上。
如何认真地解决它
第一步,用真实用户数据来测,别只在你自己那台连着光纤的笔记本上测。Chrome User Experience Report 和 Search Console 会告诉你真实顾客承受的 LCP——在他们的手机上,在他们的网络里。那才是算数的真相。
接着,找出你结账页上具体的那个 LCP 元素。Chrome DevTools 会准确告诉你它是哪一个。别猜。先优化这个元素,因为是它决定了这项指标。
- 预渲染或用缓存来送出结账页,把 Time to First Byte 压到 800ms 以下。
- 把所有第三方脚本改成延迟或异步加载——Facebook 像素没必要挡住支付按钮。
- 用 AVIF 或 WebP 送出关键图片,给 LCP 元素设定明确尺寸和高优先级。
- 用 font-display swap 让文字立刻出现,不必等字体。
- 砍掉首屏渲染用不到的 JavaScript,并拆分打包文件。
在投任何付费流量之前,这件事值得先做。花钱把顾客引到一个会在头四秒就把他们弄丢的结账页,毫无道理。你那是在往一个漏水的桶里灌水。
那笔没人愿意算的账
拿出你的购物车弃购率。和 Search Console 里的 LCP 数据对照一下。如果你的结账页在手机上超过 4 秒,你损失的一部分既不是价格异议,也不是信任不足。就只是慢。
而慢,是唯一一个不用改动文案里的一个字、不用动价格里的一分钱就能解决的转化问题。它靠工程来解决。这是一个在线生意能做的回报最高的投资之一。
这周就去测你的 LCP。如果它停在 4 秒,你已经知道漏洞在哪了。