如何改善 Core Web Vitals：LCP、INP 与 CLS 实用指南

Core Web Vitals 是 Google 用来描述页面加载和使用体验的三项指标：主要内容出现得有多快，用户与页面交互时响应得有多快，以及布局跳动的幅度有多大。它们是 Google 评估页面体验的依据之一，不过对排名而言，相关且有用的内容要重要得多。更多时候，它们是衡量网站“感觉快不快”的一把好尺子。

三项指标及“良好”的标准

• Largest Contentful Paint (LCP)：视口内最大的图片或文本块完成渲染的时间。良好：2.5 秒或更短；较差：超过 4 秒。
• Interaction to Next Paint (INP)：在整个访问过程中，页面对点击、点按和按键作出可见响应所需的时间。良好：200 毫秒或更短；较差：超过 500 毫秒。2024 年 3 月，INP 取代 First Input Delay 成为 Core Web Vitals 之一。
• Cumulative Layout Shift (CLS)：可见内容发生意外移动的程度。良好：0.1 或更低；较差：超过 0.25。

当 75% 的页面加载（即第 75 百分位）在每项指标上都达到“良好”阈值时，页面才算通过，移动端和桌面端分开统计。也就是说，最慢的那四分之一访客不会拖累你的成绩，但用中端手机的普通访客会算在内。

实验室数据与实际用户数据

实际用户数据来自真实访客。Google 的 Chrome UX Report 从选择加入的 Chrome 用户那里收集这类数据，统计窗口为滚动的 28 天；Search Console 的“核心网页指标”报告和 PageSpeed Insights 顶部显示的就是它。真正算数的是这份数据，但它需要足够的流量，而且变化缓慢。

实验室数据来自在受控条件下把页面加载一次，Lighthouse 就是这么做的。任何页面都能立刻得到结果，它还能告诉你某项指标为什么慢，因此是做诊断的工具。但在模拟手机上跑一次实验室测试，结果不会与访客真实的设备和网络相吻合；而且实验室测试根本无法测量 INP，因为没有人在与页面交互。Total Blocking Time (TBT)，也就是加载期间主线程因过于繁忙而无法响应的时长，是实验室中最接近的信号。

两者要结合使用：用实际用户数据判断有没有问题、修复是否奏效，用实验室数据找出原因。如果想自己采集实际用户数据，开源的 JavaScript 库 web-vitals 可以把真实访问中的这三项指标上报到你的分析工具。

改善 LCP

LCP 的时间可以拆成四段：首字节时间、浏览器开始加载 LCP 资源之前的延迟、下载该资源的时间，以及渲染之前的延迟。先找出哪一段偏长，然后：

• 加快服务器响应：使用页面缓存和 CDN，让 HTML 尽快送达。
• 让 LCP 图片尽早被发现：在 HTML 中使用普通的 <img>，而不是 CSS 背景或由 JavaScript 注入的图片，并且绝不要给它加 loading="lazy"。
• 提高它的优先级：给 LCP 图片加上 fetchpriority="high"；如果它被引用得比较晚，就预加载它。
• 把它变小：按显示尺寸提供，并采用 WebP 或 AVIF 格式，参见如何减小图片体积。
• 移除阻塞渲染的资源：内联关键 CSS，延迟加载非必要的脚本，并避免在主要内容出现之前进行大量的客户端渲染。

改善 INP

如果用户交互的那一刻，浏览器的主线程正忙着（通常是在运行 JavaScript），或者交互触发的工作要很久才能绘制出来，INP 就会变慢。

• 少发送一些 JavaScript。移除用不到的库和插件，拆分打包文件，页面中不需要交互的部分就不要进行水合（hydrate）。
• 拆分长任务。把超过 50 毫秒的工作拆成更小的片段，并在片段之间把控制权交还给浏览器，可以用 setTimeout，或者在受支持的环境中用 scheduler.yield()。
• 事件处理函数里少做事。先更新界面，再做开销大的工作；对输入事件的处理函数做防抖。
• 审查第三方脚本。在线客服挂件、标签管理器和 A/B 测试工具往往在每次交互时都运行繁重的代码。让它们晚一点加载，或者只在需要时加载。
• 把 DOM 控制在合理的规模，因为 DOM 一大，每次重新渲染都会变慢。

改善 CLS

• 给图片和视频指定尺寸：使用 width 和 height 属性，或 CSS 的 aspect-ratio，在它们加载之前就预留好空间。
• 为广告、嵌入内容和横幅预留空间。给它们的容器设置最小高度，并且不要在访客正在阅读的内容上方插入内容。
• 管好网页字体。使用 font-display: swap 或 optional，预加载关键字体，并使用度量值相匹配的后备字体（size-adjust），以减轻网页字体到位时的偏移。
• 用 transform 做动画，而不要用 top 或 height 这类会带动周围内容移动的属性。
• 让往返缓存（back/forward cache）发挥作用：避免使用 unload 处理函数，这样用户返回时页面能瞬间恢复，不会发生偏移。

Rudra 能帮上什么

免费网站速度检查工具会以默认的移动端模拟环境运行一次 Lighthouse 实验室测试。每项指标都会显示实测值，注明这是单次运行得到的实验室测量结果，并与公开的阈值进行对比：LCP 2.5 秒 / 4 秒，CLS 0.1 / 0.25，TBT 200 / 600 毫秒。未通过的审计项会列出最多五个相关的文件或元素以及预计可节省的量，让你知道从哪里下手。它不测量 INP，也不包含实际用户数据；这些请到 Search Console 或 PageSpeed Insights 中查看。至于页面整体缓慢的原因，参见网站为什么这么慢。

一套行之有效的流程

1. 查看 Search Console 的“核心网页指标”报告，找出是哪项指标不达标、出在哪一组页面上。
2. 从这组页面中挑一个有代表性的，多跑几次实验室测试。
3. 先解决影响最大的原因，部署上线，再在实验室里重新测试。
4. 等实际用户数据更新之后（统计窗口为 28 天）再评判效果。