Core Web Vitals：B2B 独立站该达到的三条线

先说结论：官方定义的是三条线，我们多盯的是第四条

谷歌官方的 Core Web Vitals 只有三个指标：最大内容绘制 LCP、交互到下一次绘制 INP、累计布局偏移 CLS。谷歌官方文档把这三项称作 Core Web Vitals 本体，首字节时间 TTFB 不在这个名单里。

互旦的技术SEO底座标准里，TTFB 也有一条硬阈值，只是它不算官方三条线。原因不复杂：TTFB 是前面三项的地基，服务器吐出第一个字节都要 800 毫秒以上，LCP 和 INP 大概率也好不了。

四条线放在一张表里看最直观，第四列专门标出官方地位，免得对外措辞时把 TTFB 也说成 Core Web Vitals 的一部分。

这个区分不是抠字眼。给客户或老板汇报时，把 TTFB 说成官方 Core Web Vitals 的一部分，一旦对方去查文档，专业度直接掉分——这也是为什么审计报告里，我坚持四条线分两栏写，一栏标官方，一栏标互旦内部补充。

见过不少服务商的报告把四条线混在一起说「Core Web Vitals 四项指标」，读起来没毛病，一被追问哪三项是官方定义就露怯。这种细节判断力，比任何一张漂亮的图表都更能说明写报告的人有没有亲手做过审计。

LCP ≤2.5 秒：B2B 产品页最容易被这三样拖垮

LCP 卡在移动端首屏那个最大的元素上，B2B独立站几乎都是同一批凶手：没压缩的工厂实拍大图、自动播放的产品演示视频、加载慢的 PDF 规格书缩略图。

这条我在《独立站CMS怎么选》里从系统能力角度提过一次——图片能不能自动压缩 WebP 是 CMS 的硬要求之一。换个角度看：就算 CMS 达标，运营团队自己传的原图不压缩，照样能把 LCP 拖慢两三秒。

第三方脚本也常被忽略：在线客服插件、访客分析代码，只要挂在首屏渲染路径上，都会把 LCP 往后拖。把这类脚本的加载时机改到主要内容画完之后，比换一台更贵的服务器管用得多。

这类性能项我们做独立站建设时会直接列进验收清单，不留给上线之后再补课。

排查顺序我一般固定：先用 Lighthouse 的 LCP 元素定位功能看清楚拖后腿的到底是哪一张图或哪一段视频，再决定是压缩、延迟加载，还是干脆换成静态封面图加点击播放。

不看清元素就直接全站压图，经常压错地方。

首屏之内能看到的图片，我一般要求控制在 3 张以内，多出来的全部延迟加载。

INP ≤200 毫秒：表单和筛选器才是真正的测试场

INP 测的是页面对任意一次交互的反应速度，不只是第一次点击——这是它和被取代的那个旧指标最大的区别：旧指标只看第一次交互，INP 看的是整个访问过程里最差的那一次。

B2B 站最容易在三个动作上翻车：提交询盘表单时的卡顿、产品分类筛选器点了没反应、切换语言或币种时页面冻住半秒。买家在这几个动作上等得越久，放弃询盘的概率越高。

病因也比较集中：一次性加载的大体积 JS、没有拆分优先级的第三方脚本，客服、热力图、广告像素全挤在同一时间段执行。诊断时先看这几类脚本占了多少主线程时间，比盲目升级服务器更对症。

多步骤询盘表单还有一个容易被漏掉的雷：每敲一个字就触发一次实时校验或联想搜索，主线程被这些校验函数占满，买家打字都会感觉到卡顿。

给校验函数加一点防抖延迟，每输入停顿后再校验一次而不是逐字触发，往往比重写整个表单组件见效更快。

B2B 独立站还有一个国内团队容易忽略的交互场景：多语言切换和多币种选择器。

海外买家进站第一件事经常是先换语言或换币种确认价格区间，这两个控件卡顿，等于在买家做决定之前先劝退了一批人。

CLS ≤0.1：产品图库和 Cookie 通知条最常犯规

CLS 测的是加载过程中页面元素有没有莫名其妙跳一下。B2B 站有两个位置最容易犯规：没有预设尺寸的产品图库，和加载完页面才弹出来的 Cookie 通知条。

图片不提前声明宽高，浏览器要等图片下载完才知道该留多大空间，页面因此先挤一下再展开。促销浮层、Cookie 通知条这类迟到的元素，同样会把下面的内容顶开。

自托管字体是另一个容易被忽略的因素：网页字体没加载完时先用系统字体撑着，字体到位后行宽变了，文字跟着重排。工业品站常用的衬线字体标题，这个问题尤其明显。

排查这一项不用猜，浏览器开发者工具的性能面板里能直接看到被标红的布局偏移区域，点开就知道是哪个元素在跳。比起事后靠感觉找，这比对着页面盯半天有效得多。

广告位和推荐商品浮层同样容易犯这个错：内容先渲染出来，浮层再异步加载进场，页面被硬生生顶下去一截。

解决办法不复杂，提前给这些区域预留固定高度的占位容器，元素到位时填进去就行，不会引发二次跳动。

怎么测：field data 和 lab data，B2B 决策者该看哪个

搜索控制台的 Core Web Vitals 报告用的是 field data——谷歌官方帮助文档把它描述为真实用户的匿名性能数据，来自 Chrome 用户实际访问时的采集。PageSpeed Insights 这类工具给的是 lab data，是模拟环境里跑出来的单次测试结果。

两者用途不一样：field data 按网址分组，告诉你这一类页面整体过没过线，适合拿来排优先级；lab data 针对单个网址，适合上线前逐页排查具体是哪个元素拖了后腿。

很多团队只盯 lab data 就上线，是因为它反馈快、看着直观，但它测的是单次模拟环境，跟真实访客在自己手机、自己网络下打开时的体验可能有落差。

两组数据对不上时，我更信 field data，它才是买家真实感受到的那个版本。

落到执行上，我一般每月固定抽查 5 个典型页面：首页、两个流量最大的产品页、一个筛选结果页、一个询盘表单页，四项指标一次性截图存档，方便按月对比趋势，而不是等出问题才想起来查。

我的做法是倒着用：先看 Search Console 的分组报告，挑出没过线的那一类页面，再用 PageSpeed Insights 逐个诊断。反过来先测单页再猜整体，容易被个例带偏。

检查节奏也值得固定下来：field data 是滚动窗口内真实访客数据的汇总，改完代码不会立刻反映在报告里，要等新一批真实访问数据积累够了才看得出趋势。

上线当天就去查 Search Console 说「改完还是不达标」，多半是数据还没更新，不是修复没生效。

这四条线本身不产生询盘，但决定内容能不能被完整看到——技术底座没清完不投内容的判断逻辑，我在《技术底座五项》里写过一次，CWV 是清完底座之后的下一关。

把它和内容排期放进同一张表，是互旦B2B 出海解决方案里最省钱的一个动作。

— FELIX

常见问题

LCP、INP、CLS 和 TTFB 到底哪几个才是官方的 Core Web Vitals？

官方只认三个：LCP、INP、CLS。TTFB 不在官方定义的 Core Web Vitals 名单里，是我们自己加的第四条阈值，因为它决定前三项能不能达标。四个都要测，但对外只能说前三个叫 Core Web Vitals——混着说、把 TTFB 也算进官方三项，是审计报告里最容易被内行追问出破绽的一句。

INP 和它取代的旧指标有什么区别？

旧指标只测页面第一次交互的响应速度，INP 测的是整个访问过程里所有交互里最差的那一次。首屏很快、但表单提交卡顿的页面，以前能蒙混过关，现在过不了。

field data 和 lab data 差在哪，该信哪个？

field data 来自真实访客的 Chrome 匿名数据，按网址分组，反映的是大盘情况；lab data 是单次模拟测试，适合定位具体页面的具体问题。排优先级看 field data，查病因看 lab data，两者配合用，不是二选一。

Core Web Vitals 不达标，排名一定会掉吗？

不一定。它是页面体验信号，但很少是排名波动的首要原因，技术底座的 P0 级故障才是。三项全绿是内部目标，不是满分要求，先确认底座没有 P0 故障，再来抠 CWV 更合理。

B2B 独立站最该优先修哪个指标？

没有统一答案，取决于站的病灶：图片站多半先卡 LCP，交互复杂的筛选和表单页多半卡 INP。用 Search Console 的分组报告先找出哪一类页面集中不过线，再决定优先级，不要凭感觉猜。

没有专门的技术团队，怎么低成本先测一遍？

打开 PageSpeed Insights，输入首页和一个典型产品页的网址就能看到四项数据和具体建议——这是 lab data，单次模拟测试，马上就有结果。有 Search Console 权限的话，再看 CWV 报告里的分组结果，那是 field data，反映的是真实访客的大盘情况，两步搭配着看才靠谱。

相关文章

专栏延伸与诊断专案：本文收录于 外贸独立站专栏。进阶排查建议对照阅读：传统制造工厂从阿里国际站/展会转独立站：90天冷启动路线图 · 外贸建站验收标准与 SEO 月报真伪核查表。