Core Web Vitals：性能指标、阈值与优化优先级
一、三个指标到底在测什么
Core Web Vitals 不是一个分数，是三个相互独立的体验指标组合。理解每个指标测什么，才知道该改哪里。
| 指标 | 全称 | 测量内容 | 合格线 | 需改进 |
|---|---|---|---|---|
| LCP | Largest Contentful Paint | 首屏最大元素渲染完成时间 | ≤ 2.5 秒 | 2.5 至 4 秒 |
| INP | Interaction to Next Paint | 用户交互到下一帧绘制的延迟 | ≤ 200 毫秒 | 200 至 500 毫秒 |
| CLS | Cumulative Layout Shift | 非预期布局偏移累计分 | ≤ 0.1 | 0.1 至 0.25 |
| TTVC | Time to First Contentful Paint 衍生 | 首个有用内容绘制时间 | ≤ 1.8 秒 | 1.8 至 3 秒 |
两个关键认知。第一，75 分位：Google 判定你页面好不好，看的是 75% 的真实用户在这个指标上的表现，不是平均值，也不是最快用户。第二，INP 在 2024 年 3 月正式取代 FID，从此交互延迟成为核心指标——这对装了一堆在线客服、营销自动化、聊天弹窗的 B2B 官网影响最大，因为这些脚本正是主线程阻塞的主因。
性能优化不是孤立工作，它和 媒体资产治理 是同一件事的两面：图片没治理好，LCP 永远下不来；脚本没治理好，INP 永远不合格。站内监控体系怎么建，见 站点监控与告警清单。
二、数据源：三个工具各看什么
很多团队优化性能时拿错了数据，调了一周发现指标根本没改善，因为看的是实验室值。
| 工具 | 数据类型 | 采样 | 适用场景 | 局限 |
|---|---|---|---|---|
| PageSpeed Insights | 实验室 + 现场混合 | 单次跑测 + 28 天 CrUX | 单页快速诊断 | 实验室值与真实用户有差距 |
| CrUX | 现场数据 | Chrome 用户匿名上报 | 看真实分布 | 小流量站样本不足 |
| Search Console | 现场数据汇总 | 28 天滚动 | 按模板看趋势 | 无单页下钻 |
| Lighthouse CI | 实验室数据 | 本地跑测 | 部署前回归 | 不能代表线上真实用户 |
| Web Vitals .js | 自定义现场埋点 | 自己的用户 | 小站补样本 | 需开发投入 |
实操原则：用 Search Console 的 Core Web Vitals 报告定位哪个模板有问题，用 PageSpeed Insights 单页下钻找瓶颈，用 Lighthouse CI 在每次发版前做回归。不要反过来——拿实验室分数当线上成绩，是性能优化最常见的自欺。
三、LCP 优化：首屏大图是头号敌人
B2B 官网的 LCP 80% 问题出在 hero 大图和首屏轮播。
| 瓶颈 | 典型表现 | 优化动作 | 预期收益 |
|---|---|---|---|
| 首图未压缩 | hero 图 500KB 以上 PNG | 转 WebP/AVIF，质量 80，srcset 多尺寸 | LCP 降 0.5 至 1.5 秒 |
| 首图未预加载 | 浏览器晚发现 hero 图 | head 加 preload 指向首图 | LCP 降 0.2 至 0.5 秒 |
| 字体阻塞渲染 | 自定义字体晚加载导致白屏 | font-display: swap，只加载需要字重 | LCP 降 0.3 至 0.8 秒 |
| 服务器响应慢 | TTFB 超 1.8 秒 | 上 CDN、开 HTTP/2、PHP 缓存 | LCP 降 0.4 至 1 秒 |
| 第三方脚本延迟首绘 | 头部追踪脚本阻塞 | defer 或延迟到 idle 后加载 | LCP 降 0.2 至 0.6 秒 |
一个被忽视的点：B2B 官网常把工厂全景、产品大图作为 hero，这张图往往是 2MB 以上的摄影原图。压缩到 200KB 以内、用 WebP、加 preload，三件事做完 LCP 通常能砍一半。服务器在国内、客户在欧美时，TTFB 天然偏高，CDN 必须上。
四、INP 优化：第三方脚本是主犯
INP 取代 FID 后，B2B 官网普遍翻车，因为这类站点装了太多营销和客服脚本。
| 脚本类型 | 常见来源 | 对 INP 影响 | 处理方式 |
|---|---|---|---|
| 在线客服 | Intercom、Zendesk、Tawk | 主线程长任务 200 至 800ms | 首屏后延迟 3 秒加载，或滚到底部再加载 |
| 营销自动化 | HubSpot、Marketo、Pardot | 表单与弹窗阻塞交互 | 只在目标页面加载，非目标页移除 |
| 热图与分析 | Hotjar、FullStory | 录制脚本持续占用主线程 | 采样 10% 用户，非全量录制 |
| 聊天弹窗 | WhatsApp、企业微信浮窗 | 点击弹窗延迟 | 用原生按钮，点击后再加载脚本 |
| 自定义轮播 | 首页产品轮播 | 自动播放 JS 长任务 | 改 CSS 轮播，停自动播放 |
判断瓶颈用 Chrome DevTools 的 Performance 面板录制一次页面交互，看 Main 线程上的紫色长任务，谁占的时间最长就先处理谁。原则：任何首屏非必要的脚本，都推迟到用户首次滚动或 idle 5 秒后再加载。插件选择上要克制，参考 出海站点四个插件组合，装得越多 INP 越难合格。
五、CLS 优化：给所有媒体定尺寸
CLS 是最容易修的指标，但也是最常被忽略的。
| 偏移来源 | 原因 | 修复方法 | 修复后 CLS |
|---|---|---|---|
| 图片无尺寸 | img 缺 width/height | 加宽高属性或 aspect-ratio | 接近 0 |
| 广告位预留不足 | 广告异步填充撑开 | 容器预设最小高度 | 降 0.05 至 0.15 |
| 字体交换 | FOIT/FOUT 导致重排 | font-display: swap，预留回退字体尺寸 | 降 0.02 至 0.08 |
| 动态插入内容 | 推荐位、相关文章后插入 | 占位容器预留高度 | 降 0.05 至 0.1 |
| 懒加载图晚到 | loading=lazy 图晚加载推挤下方 | 占位图或 aspect-ratio | 降 0.03 至 0.07 |
一条硬规则：页面上任何 img、video、iframe，在 HTML 里必须写 width 和 height 属性，CSS 用 aspect-ratio 保证响应式。这件事不需要开发排期，模板改一次全站受益。可访问性与性能在尺寸预留上是同源工作，见 B2B 站点可访问性范围。
六、优化优先级与迭代节奏
| 阶段 | 周期 | 目标 | 动作 | 验收指标 |
|---|---|---|---|---|
| 第一周 | 诊断 | 定位问题模板 | Search Console 拉 28 天数据，列最差 10 页 | 问题模板清单 |
| 第二周 | LCP 攻坚 | 所有模板 LCP 进 2.5 秒 | 图片压缩 + preload + 字体优化 | PSI LCP 分布 |
| 第三周 | INP 攻坚 | 第三方脚本减量 | 延迟加载、采样录制、删非必要脚本 | 长任务数量降 50% |
| 第四周 | CLS 收尾 | 全站 CLS 低于 0.1 | 宽高属性、占位容器 | GSC 无 CLS 错误页 |
| 持续 | 监控 | 发版不回退 | Lighthouse CI 每次部署跑测 | 分数不低于上版本 |
网站维护本身有固定节奏，性能只是其中一项，见 月度六项维护任务。改版或迁移后性能容易回退，要和 迁移 301 与 SEO 保全 一起回归。
FAQ 常见问题
写在最后
Core Web Vitals 不是技术团队的独角戏，是内容、设计、营销三方共同背的指标：图片大小归内容，脚本加载归营销，布局偏移归设计。把这三个人拉到同一张表上，按 LCP、INP、CLS 的顺序各修两周，一个季度内全站及格是可实现的。
落地三步：本周从 Search Console 拉最差 10 个模板列清单；第二周把 hero 图压缩加 preload；第三周把客服和营销脚本全部延迟加载。做完这三步再看 GSC，不通过率通常能下降一半以上。
一句可以记住的话：性能优化的钱要花在真实用户身上——看现场数据、治首屏大图、延后第三方脚本，比跑分满分重要十倍。