上个月一个 B2B 数据工具客户找我们，说后台打开"特别慢"，可 PageSpeed 跑出来 LCP 1.3 秒，三项指标全绿。我们跟了 20 个真实用户的操作录屏，问题不在渲染，在于他们要等 2.4 秒才看到数据。Core Web Vitals 测的是"画出来"，不是"能不能用"。
骨架屏把 LCP 做漂亮了
这个产品的首屏是仪表盘。骨架屏 0.3 秒就出现了，LCP 元素被记为骨架屏里的标题文字，所以 1.3 秒这个数很好看。但真正的报表数据来自一个 2.4 秒才返回的接口，用户盯着骨架屏转圈，感受就是慢。
同类情况还有三种：
- 图片用渐进式加载，LCP 记的是低清图首次渲染的时间
- 按钮渲染出来了，JS 还没加载完，点了没反应，这属于 INP 的范畴
- 字体 swap 后文字重绘，LCP 记的是第一次绘制
指标没坏，只是它衡量的是"页面出现了"，不是"页面能用了"。
我们补了两条自建埋点
从今年 3 月开始，我们给客户站加两条埋点，用 PerformanceObserver 加自定义打点：
- 首屏关键数据到位时间：接口 resolve 到第一次渲染完成的间隔
- 首次可用交互时间：用户第一个真实点击得到响应的时刻
这两个数不需要精确到毫秒，能看出量级就够。上面那个客户，数据到位时间 P75 是 2.6 秒，LCP 的 P75 是 1.4 秒。差出来的这 1.2 秒，就是用户嘴里那个"慢"。
别拿分数当体验的替代品
我的立场很直接：PSI 分数是给外人看的，真实用户指标是给自己看的。B2B 软件站如果只盯 LCP、INP、CLS 三个数，会漏掉一整类问题——数据链路的等待。
SaaS 后台、控制台、数据看板这类产品，用户对"多久能用"的敏感度远高于"多久能看见"。这类站的性能优化，接口和渲染必须一起看，单测前端没有意义。
怎么查：抽 20 个真实用户会话录屏，找"页面已加载但用户停顿超过 2 秒才开始操作"的片段。这类片段占比超过三成，就别再修 LCP 了，去查接口和首屏数据编排。
顺带说下取舍：给首屏数据做串行请求还是并行，很多团队为了页面的视觉顺序选择串行，代价就是可用时间翻倍。我们的做法是并行拉取、按视觉顺序渲染，宁可多一次请求，也不让用户在骨架屏上等。
两个常被问到的问题
Q：这种站还要不要做 Core Web Vitals？
要做，但别把它当验收标准。LCP、INP、CLS 是及格线，及格之后用户满不满意，取决于数据什么时候到。我们的做法是两套指标并列看，谁差修谁。
Q：怎么跟不懂技术的老板解释这件事？
别讲指标定义，讲他的使用场景。我就问了一句：你早上打开后台，看到表格出来能用，需要几秒？他想了想说三四秒。然后我把 2.6 秒的数据放到他面前，他就明白了。用户感知的时间，才是要优化的那个数。
元析智能
为软件公司做 SEO 和 GEO 优化