Core Web Vitals是Google在2020年推出的网页性能核心指标，包括LCP、FID、CLS三个指标，已经成为Google搜索排名的重要因素。本文从底层原理出发，深入剖析这三个指标的计算机制、测量方法和优化策略，帮你真正理解Core Web Vitals，而不是只记住几个阈值。

一、为什么需要Core Web Vitals

在Core Web Vitals出现之前，网页性能指标有很多：加载时间、首字节时间（TTFB）、DOMContentLoaded、onLoad、Speed Index、First Meaningful Paint等等。这些指标各有侧重，但都有一个共同的问题：它们不能准确反映用户的真实体验。

比如，一个页面onLoad时间很短，但用户看到的主要内容加载很慢，或者页面元素跳动导致用户点错按钮，用户体验依然很差。传统的性能指标无法捕捉这些用户感知层面的问题。

Google在2020年推出了Core Web Vitals（核心网页指标），旨在用三个简单、统一的指标，准确衡量用户体验的三个关键方面：

  • 加载体验：LCP（Largest Contentful Paint，最大内容绘制）
  • 交互体验：FID（First Input Delay，首次输入延迟）
  • 视觉稳定性：CLS（Cumulative Layout Shift，累积布局偏移）

这三个指标合在一起，构成了Core Web Vitals，Google将其作为搜索排名的因素之一，推动整个Web生态关注用户体验。

下面分别剖析这三个指标的底层原理。

二、LCP：最大内容绘制

LCP衡量的是页面主要内容加载完成的时间。具体来说，它记录的是视口中最大的内容元素（图片、视频、文本块等）渲染完成的时间点。

1. 为什么是"最大内容"而不是"首屏"？

以前的指标比如First Paint（首次绘制）、First Contentful Paint（首次内容绘制），记录的是第一个像素或第一个内容元素出现的时间。但这些元素可能很小（比如一个导航栏、一个小图标），不代表用户真正关心的主要内容。

LCP选择视口中最大的内容元素，因为这个元素通常是页面的主要内容（比如文章的头图、产品页的主图、视频的封面），它加载完成的时间更能反映用户感知到的"页面加载完成"。

2. LCP考虑哪些元素？

目前LCP只考虑以下几种元素：

  • <img>元素
  • <image>元素（SVG中的图片）
  • <video>元素的封面图
  • 通过url()加载的背景图元素
  • 包含文本节点或内联文本元素的块级元素

随着规范的演进，可能会加入更多元素类型。

3. LCP是怎么计算的？

LCP的计算机制比较特殊，它不是一次性确定的，而是一个不断更新的过程：

  1. 浏览器在渲染过程中，不断报告"当前最大的内容元素"和它的绘制时间
  2. 只要有更大的元素绘制完成，LCP就更新为这个新元素的绘制时间
  3. 当用户与页面发生交互（点击、滚动、按键等）后，LCP就停止更新了，因为用户交互后页面内容可能发生变化，不再代表初始加载体验
  4. 最终的LCP值是停止更新前记录的最大元素的绘制时间

这个机制叫"最大内容绘制"，它的设计考虑了页面内容逐步加载的情况：先加载小元素，再加载大元素，LCP会跟着更新，直到最大的那个出现。

4. LCP的阈值

Google给出的LCP评估标准：

  • 良好：<= 2.5秒
  • 需要改进：2.5秒 - 4秒
  • 较差：> 4秒

要达到"良好"，75%的页面访问（包括移动端和桌面端）的LCP都要在2.5秒以内。

5. LCP优化策略

LCP慢的常见原因和优化方法：

  • 服务器响应慢：优化后端性能，使用CDN，缓存，TTFB控制在600ms以内
  • 渲染阻塞的JS和CSS：内联关键CSS，延迟加载非关键CSS，JS用async/defer
  • 资源加载慢：优化图片（压缩、WebP、响应式图片），预加载关键资源，使用HTTP/2
  • 客户端渲染：SSR或SSG，减少JS渲染时间，关键内容服务端输出

一个实用的优化思路：找到LCP元素，然后针对这个元素做优化。比如LCP元素是一张大图，那就优化这张图的加载（压缩、预加载、CDN）；如果LCP元素是文本块，那就优化字体加载和渲染阻塞资源。

三、FID：首次输入延迟

FID衡量的是用户第一次与页面交互（点击按钮、点击链接、输入文字等）到浏览器实际开始处理这个交互的时间。

1. 为什么是"首次"输入？

第一次交互的体验对用户印象最深。如果用户第一次点击按钮就有明显延迟，用户会觉得这个页面很卡、很慢，即使后续交互很流畅，第一印象也已经差了。

而且，首次输入延迟通常发生在页面加载的过程中，这时候主线程可能还在执行大量的JS，最容易出现延迟。所以FID能很好地衡量页面在加载阶段的交互响应能力。

2. FID的底层原理

FID的本质是主线程阻塞。浏览器的主线程负责解析HTML、执行JS、渲染页面、处理用户交互等所有任务。当主线程正在执行一个耗时很长的JS任务时，用户的交互事件只能在事件队列里等着，直到主线程空闲了才能处理。这个等待时间就是FID。

所以FID反映的是：在页面加载过程中，主线程的繁忙程度。如果主线程被大量JS占用，FID就高；如果主线程空闲，FID就低。

FID只测量事件处理的等待时间，不包括事件处理本身的执行时间和页面更新时间。也就是说，FID是从用户点击到浏览器开始执行事件处理器的时间差。

3. FID的阈值

  • 良好：<= 100毫秒
  • 需要改进：100毫秒 - 300毫秒
  • 较差：> 300毫秒

100毫秒是什么概念？人眼能感知到的延迟大约是100毫秒，低于这个值用户会觉得是即时响应。

4. FID优化策略

FID高的根本原因是主线程被阻塞，优化方向就是减少主线程的工作量：

  • 拆分长任务：把执行时间超过50ms的长任务拆分成多个小任务，用setTimeout、requestIdleCallback等方式让主线程有机会处理用户交互
  • 减少JS体积：代码分割、tree-shaking、移除未使用的代码，减少需要下载和解析的JS量
  • 延迟加载非关键JS：首屏不需要的JS用动态import延迟加载，不要在首屏加载时执行
  • 使用Web Worker：把计算密集型任务放到Web Worker中，不占用主线程
  • 优化第三方脚本：广告、统计、社交分享等第三方脚本经常是长任务的来源，评估是否必要，必要的话延迟加载或异步加载

一个实用的工具是Long Tasks API，可以监控页面中的长任务，找到阻塞主线程的罪魁祸首。

5. FID的局限和演进

FID有一个局限：它只测量首次输入，而且只测量等待时间，不测量事件处理时间。如果事件处理器本身执行很慢，用户依然会觉得卡，但FID反映不出来。

Google后来推出了INP（Interaction to Next Paint，交互到下一次绘制）作为FID的替代指标，它测量所有交互（不只是首次）的完整响应时间（包括等待、处理、渲染），更全面地反映交互体验。2024年INP正式取代了FID成为Core Web Vitals的一员。但在2020年，FID还是核心指标。

四、CLS：累积布局偏移

CLS衡量的是页面在整个生命周期中发生的所有非预期布局偏移的累积分数。简单说，就是页面元素在加载过程中跳动了多少。

1. 什么是布局偏移？

你有没有遇到过这种情况：正在看一篇文章，突然上面的图片加载出来了，把文字挤到下面去了，你正在看的内容跳走了；或者正要点击一个按钮，突然上面弹出一个广告，按钮被挤下去了，你点错了地方。这就是布局偏移。

布局偏移非常影响用户体验，尤其是在移动端，屏幕小，偏移的影响更大。CLS就是用来量化这种视觉不稳定的指标。

2. CLS是怎么计算的？

CLS的计算涉及两个概念：

  • 影响分数（Impact Fraction）：发生偏移的元素在视口中所占的比例。比如一个元素占了视口高度的50%，它的影响分数就是0.5。
  • 距离分数（Distance Fraction）：元素偏移的距离占视口尺寸的比例。比如元素向下移动了视口高度的10%，距离分数就是0.1。

一次布局偏移的分数 = 影响分数 × 距离分数。CLS就是页面生命周期中所有非预期布局偏移的分数之和。

举个例子：一个占视口50%的元素向下移动了视口高度的20%，这次偏移的分数就是0.5 × 0.2 = 0.1。如果页面发生了三次这样的偏移，CLS就是0.3。

3. 什么是"非预期"偏移？

不是所有的布局偏移都算CLS。用户主动触发的布局变化（比如点击展开菜单、输入文字后出现搜索建议）不算，因为这是用户预期的。只有那些非预期的、突然发生的偏移才算。

浏览器通过一个"会话窗口"机制来区分：如果两次偏移之间有用户交互（500ms以内），后面的偏移就不算。这样可以排除用户操作导致的布局变化。

4. CLS的阈值

  • 良好：<= 0.1
  • 需要改进：0.1 - 0.25
  • 较差：> 0.25

CLS是一个没有单位的分数，0.1意味着页面整体偏移了大约10%的视口面积。

5. CLS优化策略

布局偏移最常见的原因和优化方法：

  • 图片没有尺寸：给<img>标签设置width和height属性，或者用CSS aspect-ratio，让浏览器在图片加载前就预留好空间
  • 广告、嵌入内容没有预留空间：广告位、嵌入的视频/地图等，提前设置好尺寸，不要等内容加载出来再撑开
  • 动态插入内容：在已有内容上方插入新内容（比如公告、推荐）会导致偏移，尽量在下方插入，或者用动画平滑过渡
  • 字体加载导致闪烁：字体加载前后文字大小变化会导致偏移，用font-display: optional，或者预加载字体，或者给字体设置合适的fallback
  • JS操作DOM导致偏移：在DOM渲染完成后再操作，避免在加载过程中频繁修改DOM

一个简单有效的原则：任何会改变页面布局的元素，都要在加载前预留好空间。这样不管内容什么时候加载出来，布局都不会变。

五、三个指标的关系

LCP、FID、CLS三个指标分别衡量了用户体验的三个不同维度，它们之间既有区别又有联系。

区别：

  • LCP关注加载，衡量用户多久能看到主要内容
  • FID关注交互，衡量用户第一次操作的响应速度
  • CLS关注稳定，衡量页面元素是否跳动

联系：

  • 它们都和页面加载过程密切相关，加载阶段的性能问题会同时影响多个指标
  • 优化方法有共通之处：减少JS体积、优化资源加载、使用CDN等，对三个指标都有帮助
  • 它们共同构成了用户体验的完整画像：一个好的页面，要加载快、响应快、不跳动

需要注意的是，三个指标要同时达标，不能只优化一个。比如LCP很快但CLS很高，用户依然会觉得体验差；FID很好但LCP很慢，用户等半天才能看到内容，体验也不好。

六、如何测量Core Web Vitals

了解了原理之后，还要知道怎么测量。Google提供了多种测量工具：

1. 实验室测量

  • Lighthouse：Chrome DevTools内置，或独立运行，能给出三个指标的分数和优化建议
  • Chrome DevTools Performance面板：可以看到详细的性能分析，包括LCP标记、长任务、布局偏移等
  • web.dev/measure：在线工具，输入URL就能得到性能报告

实验室测量的优点是可控、可重复，适合开发阶段调试。缺点是不能反映真实用户的体验（受测试环境影响）。

2. 真实用户测量（RUM）

  • Chrome User Experience Report（CrUX）：Google收集的真实Chrome用户数据，PageSpeed Insights和Search Console都用这个数据源
  • web-vitals JS库：Google官方的JS库，可以在自己的网站上采集真实用户的Core Web Vitals数据，上报到分析系统
  • Search Console：Google Search Console有专门的"网页体验"报告，展示网站的Core Web Vitals数据

真实用户测量反映的是实际用户的体验，更有参考价值，也是Google排名使用的数据。建议实验室和真实用户测量结合使用。

七、优化的优先级和思路

面对三个指标，应该怎么安排优化优先级？我的建议是：

  1. 先看数据：用工具测量，看哪个指标最差，优先优化最差的那个
  2. LCP优先：通常LCP是最容易出问题、影响最大的指标，先把LCP优化好
  3. CLS其次：CLS优化成本低、见效快，给图片和广告加尺寸就能解决大部分问题
  4. FID最后：FID优化相对复杂，需要分析JS执行情况，适合在LCP和CLS之后做

优化的整体思路：

  • 减少资源体积（图片、JS、CSS）
  • 减少关键路径上的资源（内联关键CSS、延迟非关键JS）
  • 加快资源加载（CDN、缓存、HTTP/2、预加载）
  • 减少主线程阻塞（拆分长任务、Web Worker）
  • 预留布局空间（图片尺寸、广告位尺寸）

八、写在最后

Core Web Vitals代表了Web性能优化从"技术指标"到"用户体验指标"的转变。以前我们优化性能，关注的是加载时间、请求数这些技术指标；现在我们关注的是用户能不能快速看到内容、能不能流畅交互、页面会不会跳动，这些真正影响用户感受的指标。

理解Core Web Vitals的底层原理，而不是只记住几个阈值，能帮助我们更有针对性地优化性能。知道LCP是怎么计算的，就知道要优化最大内容元素；知道FID是主线程阻塞，就知道要拆分长任务；知道CLS是布局偏移，就知道要预留空间。

Web性能优化是一个持续的过程，不是做一次就完了。随着页面内容的变化、新功能的加入，性能可能会退化。建立持续的性能监控和优化机制，才能保证用户体验始终良好。

希望这篇原理剖析能帮你深入理解Core Web Vitals，做出更快、更稳、更好的网页。