为什么 Core Web Vitals 对 SEO 至关重要
Core Web Vitals 于 2021 年 5 月被确认为 Google 的排名信号。而早在近一年前，Google 就已宣布了这一调整：
"我们将引入一项新的信号，把 Core Web Vitals 与现有的页面体验信号相结合，从而全面反映用户在网页上的体验质量。"
— Google Search Central，《评估页面体验，打造更好的网络》（2020 年 5 月）
此后，Google 不断提高它们在排名算法中的权重，并淘汰了旧的 Page Experience（页面体验）信号，转而采用以 CWV 为核心的测量方式。
2024 年 3 月，Google 正式用 INP（Interaction to Next Paint，交互到下一次绘制）取代 FID（First Input Delay，首次输入延迟）作为交互性指标——这一重大变化让许多团队措手不及：
"今天，我们宣布 INP 将正式成为一项 Core Web Vital，并于今年 3 月 12 日取代 FID，而 FID 也将在这一过渡中被弃用。"
— web.dev，《Interaction to Next Paint 于 3 月 12 日成为 Core Web Vital》（2024 年）
那些曾针对 FID 做过优化的网站发现，自己的 INP 分数要差得多，因为 INP 衡量的是所有交互的完整成本，而不只是第一次交互。
Core Web Vitals 对排名的直接影响是真实存在的，但很微妙。Google 已确认它是一个决胜信号（tiebreaker），而非主导因素——CWV 表现差但内容优秀的页面，通常会排在 CWV 满分但内容差的页面之前。但在内容质量相近的竞争性搜索结果页（SERP）中，CWV 就成了拉开差距的关键。
三大 Core Web Vitals 速览
最大内容绘制（LCP）
LCP 衡量视口中最大的可见元素完成加载所需的时间。"最大元素"通常是主视觉图（hero image）、一大段文本块或视频封面帧。LCP 代表页面的主要内容让用户感觉"已经加载完成"的那一刻。
LCP 表现差的常见原因
- 服务器响应时间过长（TTFB，首字节时间）。 如果服务器响应超过 600ms，无论做了多少其他优化，LCP 几乎都会很差。可使用 CDN（内容分发网络）、优化服务端渲染（SSR），并考虑边缘缓存。
- 渲染阻塞资源。
<head>中的 CSS 和 JavaScript 会阻塞浏览器绘制页面。对非关键脚本使用defer或async，并将关键 CSS 内联。 - 图片加载缓慢。 LCP 元素最常见的就是一张图片。如果图片没有预加载、尺寸不合适，或没有使用 WebP/AVIF 等现代格式，加载就会很慢。
- 客户端渲染（CSR）。 如果 LCP 元素由 JavaScript 渲染，浏览器必须等 JS 下载、解析并执行完成后才能绘制它。服务端渲染（SSR）或静态生成（SSG）能显著改善 JS 密集型页面的 LCP。
如何优化 LCP
- 为 LCP 图片添加
<link rel="preload" as="image">，让浏览器尽早获取它。 - 确保 LCP 图片显式声明
width和height属性，并使用现代格式（WebP 或 AVIF）。 - 把关键图片从 JavaScript 中移出、放进静态 HTML，使其能被浏览器的预加载扫描器发现。
- 将首字节时间（TTFB）控制在 600ms 以内。对静态资源和服务器渲染的 HTML 使用带边缘缓存的 CDN。
- 移除或延迟首屏不需要的渲染阻塞 CSS 和 JavaScript。
QuintoAndar 将移动端 INP 降低 80%，转化率同比增长 36%
巴西房地产平台 QuintoAndar 通过用 async/await 让出点（yield points）拆分长任务、采用 React 的 useTransition hook、从客户端移除第三方像素，并弃用 CSS-in-JS，将移动端 INP 从 1,006ms 降到 216ms。达到 INP "良好"阈值的页面占比从 42% 提升到 78%。
交互到下一次绘制（INP）
INP 衡量页面响应用户交互（点击、轻触和键盘输入）的速度。它记录的是整个页面访问期间（排除异常值后）观察到的最长交互延迟，而不只是第一次交互。INP 达到 200ms 或更低即为良好。
2024 年 3 月，INP 取代 FID（First Input Delay）成为 Core Web Vital。这一变化意义重大：FID 只衡量浏览器开始处理交互之前的延迟，而 INP 衡量的是从交互发生到下一次绘制更新的完整时间——包括执行事件处理器的时间和渲染响应的时间。
想知道自己的页面表现如何？查看你的实时 INP 分数——免费、无需注册，使用的是 Google 同款真实用户（CrUX）数据和实验室数据。
INP 表现差的常见原因
- 主线程上的长任务。 任何阻塞主线程超过 50ms 的 JavaScript 都属于长任务。长任务会阻止浏览器响应用户输入。常见原因包括：过大的 JavaScript 包、同步的第三方脚本以及复杂的事件处理器。
- 事件处理器过重。 触发大规模 DOM 更新、复杂布局重算或同步网络请求的处理器，都会延迟下一次绘制。
- 第三方脚本。 分析、聊天插件和广告脚本经常在主线程上运行，导致 INP 回退。
- 低效的 React/Vue/Angular 组件。 状态变化触发的框架重渲染会产生昂贵的更新。记忆化（memoization）、虚拟化（virtualization）和谨慎的状态管理是主要的缓解手段。
如何优化 INP
- 在 Chrome DevTools 的 Performance（性能）面板中对交互进行分析，找出交互序列中的长任务。
- 使用
scheduler.yield()或setTimeout(fn, 0)拆分长任务，让浏览器在工作块之间有时间进行绘制。 - 使用 Web Workers 把高开销的计算移出主线程。
- 把非关键的第三方脚本推迟到页面可交互之后再加载。用
async加载它们，并考虑在用户交互后才加载（例如，聊天插件仅在点击聊天按钮时才加载）。 - 对视觉更新使用
requestAnimationFrame，确保它们与浏览器的渲染管线正确批处理。
累积布局偏移（CLS）
CLS 衡量视觉稳定性——即页面加载过程中内容意外移动了多少。它是对整个会话期间发生的所有布局偏移的累计度量，并按每次偏移的大小和距离加权。CLS 分数为 0.1 或更低即为良好。
布局偏移会让用户很恼火，因为它会导致误点击：你正要点击某个按钮，内容却移动了，结果点错了地方。Google 认为这是用户体验质量的直接衡量指标。
CLS 表现差的常见原因
- 图片没有显式尺寸。 如果图片标签没有
width和height属性，浏览器就不知道要预留多少空间。图片加载后，它下面的所有内容都会发生偏移。 - 动态注入的广告和嵌入内容。 在初始渲染之后才加载的广告位会把内容向下推。用
min-height预留空间可以防止这种偏移。 - Web 字体导致的 FOUT/FOIT（字体加载闪烁）。 当 Web 字体加载并替换回退字体时，如果两者的度量（metrics）不匹配，文本就会发生重排。使用
font-display: optional，或仔细匹配回退字体的度量。 - 改变布局属性的动画。 修改
top、left、width或height的动画会导致布局偏移。改用transform和opacity——它们只作用于合成器（compositor），不会触发布局。
如何优化 CLS
- 给所有
<img>标签添加显式的width和height属性。现代浏览器会据此计算宽高比，并在图片加载前预留空间。 - 用一个设置了固定
min-height的容器 div 为广告位预留空间。 - 对需要保持比例的响应式容器，使用 CSS 的
aspect-ratio属性。 - 对动画元素优先使用
transform: translateY()，而不是top/margin-top。 - 在
@font-face声明中添加font-display: swap或optional。可考虑使用size-adjust描述符来匹配回退字体的度量。
如何测量 Core Web Vitals
现场数据 vs 实验室数据
CWV 的测量分为两类，而它们的结果常常不一致：
现场数据（Field Data）（也称真实用户监控，即 RUM）来自通过 Chrome 访问你网站的真实用户。Google 用现场数据来做排名。其主要来源是 Chrome 用户体验报告（CrUX），可在 Google Search Console、PageSpeed Insights 和 Core Web Vitals 报告中查看。你的网站需要有足够的流量才会出现在 CrUX 中——低流量页面可能没有现场数据。
实验室数据（Lab Data） 由在受控环境（无真实用户）中运行的自动化工具采集。实验室数据对任何页面都可用，不受流量限制，但它模拟的是用户环境，而不是真实测量。相关工具：PageSpeed Insights（实验室）、Chrome DevTools 的 Lighthouse、WebPageTest。
实验室数据适合调试——你可以复现特定的性能状况并追踪原因。而现场数据才是影响排名的关键。两者都要查看，但应优先解决现场数据暴露的问题。
测量 Core Web Vitals 的工具
- Google Search Console： Core Web Vitals 报告会展示所有具备 CrUX 数据的页面的现场数据。它是首选起点——能告诉你哪些页面在大规模地不达标。
- PageSpeed Insights： 针对单个 URL 提供现场数据（CrUX）和实验室数据（Lighthouse）。最适合诊断某个具体页面。
- Chrome DevTools： Performance（性能）面板和 Lighthouse 用于实验室测量。最适合调试具体问题。
- WebPageTest： 提供详细的实验室测试，包括影片帧（filmstrips）、瀑布图和多步骤测试。最适合深入诊断。
- SearchVitals： 每次网站审计都包含 CWV 现场数据和实验室数据，并附带技术问题和 GEO（生成式引擎优化）就绪度——让你把 CWV 放在其他网站健康信号的整体语境中来看。