Web Vitals是Google推出的网页性能衡量标准，其中Core Web Vitals包括LCP、FID、CLS三个核心指标。这些指标不仅影响用户体验，还会影响搜索引擎排名。本文深入剖析Web Vitals的底层原理，包括每个指标的计算方式、测量方法、影响因素以及优化策略。如果你是前端开发者，或者关注网页性能优化，希望这篇文章能帮你深入理解Web Vitals，从而更好地优化网站性能。

一、什么是Web Vitals

先简单介绍一下Web Vitals。

Web Vitals是Google在2020年推出的一套网页性能衡量标准。它的目标是提供一套统一的、易于理解的性能指标，帮助开发者衡量和优化用户体验。

Web Vitals分为两类。一类是Core Web Vitals（核心Web指标），包括三个最重要的指标：LCP（最大内容绘制）、FID（首次输入延迟）、CLS（累积布局偏移）。另一类是其他Web Vitals，包括TTFB（首字节时间）、FCP（首次内容绘制）、TTI（可交互时间）等辅助指标。

Google把Core Web Vitals作为衡量网页用户体验的核心标准，并且从2021年开始将其纳入搜索引擎排名因素。也就是说，如果你的网站Core Web Vitals不达标，搜索排名可能会受到影响。

每个Core Web Vitals指标都有三个等级：良好、需要改进、较差。

LCP的标准是：2.5秒以内为良好，2.5到4秒为需要改进，超过4秒为较差。 FID的标准是：100毫秒以内为良好，100到300毫秒为需要改进，超过300毫秒为较差。 CLS的标准是：0.1以内为良好，0.1到0.25为需要改进，超过0.25为较差。

一个网站要达到良好的Core Web Vitals，需要这三个指标的第75百分位数都达到良好水平。也就是说，75%的用户访问都要达到良好标准。

下面我分别深入剖析这三个核心指标的底层原理。

二、LCP：最大内容绘制

LCP（Largest Contentful Paint）衡量的是页面主要内容加载完成的时间。具体来说，它记录的是视口中最大的内容元素（通常是图片、视频或者大段文字）渲染完成的时间点。

1. LCP的计算原理

LCP的计算并不像看起来那么简单。浏览器在加载页面的过程中，会不断报告当前视口中最大的内容元素的渲染时间。这个过程是持续的，因为随着页面的加载，可能会出现更大的元素，或者原来的元素被移出视口。

浏览器会在以下几种情况下报告LCP候选元素：

  • 图片元素（img标签、CSS背景图、video标签的封面图）
  • 包含文本的块级元素（p、h1-h6、div等）

浏览器会持续跟踪这些元素的渲染时间，直到用户第一次与页面交互（点击、滚动、键盘输入等）。一旦用户开始交互，LCP的计算就停止了，取此时记录的最大元素的渲染时间作为最终的LCP值。

为什么要在用户交互时停止呢？因为用户交互之后，页面内容可能会发生变化，这时候的最大内容元素可能不是用户最初看到的内容了。所以LCP衡量的是用户首次看到页面主要内容的时间。

2. LCP的影响因素

影响LCP的因素主要有四个方面。

第一是服务器响应时间。服务器响应越慢，浏览器开始接收内容的时间就越晚，LCP自然就越大。TTFB（首字节时间）是衡量服务器响应时间的指标，TTFB越大，LCP通常也越大。

第二是资源加载时间。LCP元素通常是图片或者大段文本，这些资源的加载时间直接影响LCP。图片越大、网络越慢，加载时间就越长。

第三是客户端渲染。如果页面是用JavaScript动态渲染的（比如React、Vue等SPA应用），那么LCP元素需要等JavaScript加载并执行完成之后才能渲染出来，这会显著增加LCP。

第四是资源的优先级。浏览器会根据资源的类型和位置来决定加载优先级。如果LCP元素的资源优先级太低，浏览器可能会先加载其他不重要的资源，导致LCP元素加载延迟。

3. LCP的优化策略

针对这些影响因素，LCP的优化策略也有几个方向。

第一，优化服务器响应时间。可以用CDN来加速静态资源的分发，用缓存来减少服务器的计算，用HTTP/2或者HTTP/3来提高传输效率。

第二，优化LCP元素的加载。如果LCP元素是图片，可以压缩图片大小，用现代图片格式（WebP、AVIF），用响应式图片（srcset），用预加载（preload）来提前加载关键图片。如果LCP元素是文本，可以优化关键CSS，减少渲染阻塞。

第三，减少客户端渲染的影响。对于SPA应用，可以用服务端渲染（SSR）或者静态站点生成（SSG），让HTML中直接包含主要内容，而不是靠JavaScript动态渲染。

第四，优化资源加载顺序。用<link rel="preload">来预加载关键资源，用<link rel="preconnect">来提前建立连接，用fetchpriority属性来指定资源的优先级。

三、FID：首次输入延迟

FID（First Input Delay）衡量的是用户第一次与页面交互到浏览器实际能够响应这次交互的时间。比如用户第一次点击按钮，到浏览器开始处理这个点击事件之间的延迟。

1. FID的计算原理

FID只测量输入事件的处理延迟，不包括事件处理本身的执行时间，也不包括事件处理之后的页面更新时间。它只衡量浏览器主线程被占用、无法响应用户输入的那段时间。

为什么会有输入延迟呢？因为浏览器的主线程同时负责很多事情：解析HTML、执行JavaScript、渲染页面、处理用户输入等等。如果主线程正在执行一段很长的JavaScript代码，那么用户的输入事件就只能在任务队列里等着，直到主线程空闲下来才能处理。这段等待的时间就是FID。

FID只测量第一次输入的延迟，因为第一次输入通常是用户对页面响应性的第一印象，对用户体验影响最大。

FID的测量需要真实用户的交互，所以不能在实验室环境中完全模拟。在实验室中通常用TBT（Total Blocking Time，总阻塞时间）来作为FID的代理指标，TBT衡量的是首次内容绘制到可交互时间之间，主线程被长任务阻塞的总时间。

2. FID的影响因素

FID的核心影响因素是主线程的繁忙程度，尤其是JavaScript的执行。

第一是长任务。JavaScript中的长任务（执行时间超过50毫秒的任务）会阻塞主线程，导致用户输入无法及时响应。长任务越多、越长，FID就越大。

第二是JavaScript的体积和执行时间。页面加载的JavaScript越多，解析和执行的时间就越长，主线程被占用的时间就越多，FID就越大。

第三是第三方脚本。很多网站会加载各种第三方脚本，比如广告、分析、社交媒体插件等。这些脚本往往质量参差不齐，有些会执行很长时间，严重阻塞主线程。

第四是渲染工作。复杂的CSS动画、大量的DOM操作、频繁的布局计算等渲染工作也会占用主线程，影响FID。

3. FID的优化策略

FID的优化核心是减少主线程的阻塞，让浏览器能够及时响应用户输入。

第一，拆分长任务。把执行时间很长的JavaScript代码拆分成多个小任务，用setTimeout、requestIdleCallback或者Promise来让出主线程，让浏览器有机会处理用户输入。

第二，减少JavaScript的体积。删除未使用的代码（tree shaking），按需加载代码（code splitting），用更小的第三方库，压缩和混淆代码。减少JavaScript的体积可以减少解析和执行时间。

第三，优化第三方脚本。延迟加载非关键的第三方脚本（用async或者defer），或者在用户交互之后再加载。对于不重要的第三方脚本，可以考虑移除。

第四，使用Web Worker。把计算密集型的任务放到Web Worker中执行，不占用主线程。Web Worker可以在后台线程中运行JavaScript，不影响主线程的响应性。

第五，优化渲染。减少复杂的CSS动画，避免频繁的强制同步布局（layout thrashing），用contain属性来限制渲染范围。

四、CLS：累积布局偏移

CLS（Cumulative Layout Shift）衡量的是页面在整个生命周期中发生的意外布局偏移的累积量。简单来说，就是页面元素在加载过程中突然移动，导致用户体验不佳的程度。

1. CLS的计算原理

CLS的计算比LCP和FID复杂一些。它基于两个概念：影响分数和距离分数。

影响分数是指发生偏移的元素在视口中所占的比例。比如一个元素占了视口50%的面积，它发生了偏移，那么这次偏移的影响分数就是0.5。

距离分数是指元素偏移的距离占视口最大尺寸（宽度或高度）的比例。比如视口高度是800像素，元素向下移动了80像素，那么距离分数就是0.1。

一次布局偏移的分数 = 影响分数 × 距离分数。CLS就是页面加载过程中所有意外布局偏移的分数之和。

注意是"意外"的布局偏移。如果是用户交互导致的布局偏移（比如点击展开菜单），是不算在CLS里的。CLS只计算那些不是由用户交互直接导致的偏移。

CLS的计算窗口也有讲究。浏览器会把布局偏移分组到不同的会话窗口中，每个窗口最多持续5秒，窗口之间的间隔至少1秒。最终的CLS取所有窗口中最大的那个累积值，而不是整个页面生命周期的总和。这样可以避免页面长时间运行后CLS无限增大。

2. CLS的影响因素

CLS通常由以下几种情况引起。

第一是没有指定尺寸的图片和视频。如果img标签没有设置width和height，浏览器在图片加载之前不知道它的尺寸，会先预留0高度，图片加载完成之后再撑开，导致下面的内容下移。

第二是动态插入的内容。比如广告、推荐内容、通知横幅等，这些内容通常是在页面加载之后通过JavaScript动态插入的，插入的时候会把已有内容推开，造成布局偏移。

第三是网络字体。使用自定义字体的时候，浏览器会先用系统字体渲染文本，等自定义字体加载完成之后再替换，这时候文本的宽度和高度可能会发生变化，导致布局偏移。这就是所谓的"无样式文本闪烁"（FOUT）。

第四是没有预留空间的嵌入内容。比如iframe、广告位、地图等，如果没有提前预留好尺寸，加载完成之后会撑开页面，造成布局偏移。

3. CLS的优化策略

CLS的优化核心是提前为所有内容预留好空间，避免加载过程中页面布局发生变化。

第一，为图片和视频指定尺寸。在img和video标签上设置width和height属性，或者用CSS的aspect-ratio属性来固定宽高比。这样浏览器在资源加载之前就知道元素的尺寸，提前预留好空间。

第二，为动态插入的内容预留空间。如果知道广告或者推荐内容的尺寸，提前用CSS预留好位置。如果不知道具体尺寸，可以设置一个最小高度，减少偏移的幅度。最好在用户交互之后再插入内容，这样不算意外偏移。

第三，优化网络字体加载。用font-display: swap让浏览器先用系统字体渲染，等自定义字体加载完成后再替换。用<link rel="preload">预加载关键字体。还可以用size-adjust、ascent-override等CSS属性来调整字体的度量，减少字体替换时的布局变化。

第四，避免在已有内容上方插入内容。如果必须插入内容，尽量插入到视口下方，或者用动画平滑过渡，减少突然偏移带来的不适。

第五，用transform做动画。CSS动画尽量用transform和opacity，不要用改变布局的属性（比如top、left、margin、width等），因为这些属性的变化会触发布局重排，可能影响其他元素。

五、如何测量Web Vitals

了解了原理之后，还需要知道怎么测量这些指标。

1. 实验室测量

实验室测量就是在受控环境中（比如自己的电脑上）用工具来测量性能。常用的工具有Lighthouse、WebPageTest、Chrome DevTools的Performance面板等。

Lighthouse是最常用的工具，它集成在Chrome DevTools中，也可以通过命令行使用。运行Lighthouse会生成一份详细的性能报告，包括LCP、FID（用TBT代替）、CLS等指标，以及具体的优化建议。

实验室测量的优点是可复现、可对比，适合在开发过程中持续监控。缺点是不能完全反映真实用户的体验，因为用户的网络环境、设备性能、交互行为都不一样。

2. 真实用户测量

真实用户测量（RUM）就是收集真实用户访问网站时的性能数据。Google提供了免费的工具：Chrome User Experience Report（CrUX）和PageSpeed Insights。

PageSpeed Insights可以输入网址，查看该网站的真实用户Core Web Vitals数据（来自CrUX数据集），同时也会跑一次实验室测量给出优化建议。

如果想自己收集真实用户数据，可以用web-vitals这个JavaScript库。它是Google官方提供的，可以在页面中引入，然后把测量到的LCP、FID、CLS数据发送到自己的分析后台。

真实用户测量的优点是反映了真实的用户体验，数据更有参考价值。缺点是数据收集和分析比较复杂，而且需要一定的流量才能有统计意义。

3. 测量的注意事项

测量Web Vitals的时候有几个注意事项。

第一，Core Web Vitals看的是第75百分位数，不是平均值。也就是说，要保证75%的用户都能达到良好标准。平均值可能会被少数极端值影响，不能准确反映大多数用户的体验。

第二，FID需要真实用户交互才能测量。如果用户没有任何交互就离开了页面，就不会有FID数据。所以FID的数据量通常比LCP和CLS少。

第三，CLS的计算是持续的，直到页面被隐藏或者关闭。所以单页应用（SPA）在路由切换的时候也要注意避免布局偏移，否则CLS会持续累积。

六、优化的优先级和策略

三个Core Web Vitals指标都很重要，但是优化的时候可以根据实际情况排优先级。

一般来说，LCP是最容易出问题的指标，也是对用户体验影响最大的。大多数网站首先需要优化的就是LCP。可以从服务器响应、图片优化、关键资源预加载这几个方面入手。

FID通常在JavaScript比较重的网站上问题比较明显，比如SPA应用、有大量第三方脚本的网站。如果你的网站JavaScript不多，FID一般不会有太大问题。

CLS通常是最容易优化的，只要养成良好的开发习惯，为所有内容预留好尺寸，就能避免大部分布局偏移。

优化的整体策略是：先测量，找到瓶颈；然后针对最大的瓶颈做优化；优化之后再测量，验证效果；持续迭代，直到三个指标都达到良好标准。

不要盲目地做优化，每次只改一个变量，然后测量效果，确认这个改动确实有帮助。否则可能做了很多工作，但是效果不明显，甚至反而变差了。

七、写在最后

Web Vitals是Google对网页性能衡量标准的一次重要升级。它从用户体验的角度出发，定义了三个核心指标，让开发者有了明确的优化目标。

深入理解Web Vitals的底层原理非常重要。只有知道了每个指标是怎么计算的、受什么因素影响，才能有针对性地做优化，而不是盲目地照搬别人的优化方案。

Web性能优化是一个持续的过程，不是一次性的工作。随着网站内容的更新、功能的增加，性能可能会慢慢变差。所以要把性能监控集成到开发流程中，持续关注Core Web Vitals的变化，发现问题及时优化。

希望本文的剖析能帮助你更深入地理解Web Vitals，从而更好地优化网站性能，给用户带来更好的体验。

用一句话结束本文："性能优化的本质是理解用户，理解浏览器，理解每一个毫秒背后的机制。"愿每一个前端开发者都能打造出流畅、快速、用户喜爱的网站。