Web 指标是 Google 开创的一项新计划，旨在为网络质量信号提供统一指导，这些信号对于提供出色的网络用户体验至关重要。
网站所有者要想了解他们提供给用户的体验质量，并非需要成为性能专家。Web 指标计划为了简化场景，帮助网站专注于最重要的指标，即核心 Web 指标（LCP FID CLS）。
根据官方的说法，核心 Web 指标 是长期下来根据大量使用者体验所制定的指标。在这之前，Google 已针对使用者体验设置过多种评分机制，但都未真正的搔到使用者的痒处。而在推出全新的 核心 Web 指标 后 Google 甚至提到，若 75% 以上的使用者在网站中的浏览体验都能够通过以上 3 种指标（LCP FID CLS），就能够大幅的提升使用者的搜寻体验，甚至能够让原本因等待而离开的使用者减少 24%！
LCP: Largest Contentful Paint 最大内容绘制
LCP 测量加载性能。为了提供良好的用户体验，LCP 应在页面首次开始加载后的2.5 秒内发生。
LCP 指标会根据页面首次开始加载的时间点来报告可视区域内可见的最大图像或文本块完成渲染的相对时间。
示例（以下示例展示了一些热门网站上出现最大内容绘制的时间点）：
在上方的两个时间轴中，最大元素随内容加载而变化。在第一个示例中，新内容被添加进 DOM，并因此使最大元素发生了改变。在第二个示例中，由于布局的改变，先前的最大内容从可视区域中被移除。
虽然延迟加载的内容通常比页面上已有的内容更大，但实际情况并非一定如此。接下来的两个示例显示了在页面完全加载之前出现的最大内容绘制。
在第一个示例中，Instagram LOGO加载得相对较早，即使其他内容随后陆续显示，但LOGO始终是最大元素。在 Google 搜索结果页面示例中，最大元素是一段文本，这段文本在所有图像或标志完成加载之前就显示了出来。由于所有单个图像都小于这段文字，因此这段文字在整个加载过程中始终是最大元素。
FID：First Input Delay 首次输入延迟
FID 测量交互性。为了提供良好的用户体验，页面的 FID 应为100 毫秒或更短。
FID 测量从用户第一次与页面交互（例如当他们单击链接、点按按钮或使用由 JavaScript 驱动的自定义控件）到浏览器对交互作出响应，并实际能够开始处理事件处理程序所经过的时间。
CLS：Cumulative Layout Shift 累积布局偏移
CLS 测量视觉稳定性。为了提供良好的用户体验，页面的 CLS 应保持在 0.1 或更少。
CLS 测量整个页面生命周期内发生的所有意外布局偏移中最大一连串的布局偏移分数。每当一个可见元素的位置从一个已渲染帧变更到下一个已渲染帧时，就发生了布局偏移 。
您是否曾经历过在网上阅读一篇文章，结果页面上的某些内容突然发生改变？文本在毫无预警的情况下移位，导致您找不到先前阅读的位置。或者更糟糕的情况：您正要点击一个链接或一个按钮，但在您手指落下的瞬间，诶？链接移位了，结果您点到了别的东西！
大多数情况下，这些体验只是令人恼火，但在某些情况下，却可能带来真正的破坏：
布局偏移分数 = 影响分数 * 距离分数
分数计算示例：
在上图中，有一个元素在一帧中占据了一半的可视区域。接着，在下一帧中，元素下移了可视区域高度的 25%。红色虚线矩形框表示两帧中元素的可见区域集合，在本示例中，该集合占总可视区域的 75%，因此其影响分数为0.75 。
在上方的示例中，最大的可视区域尺寸维度是高度，不稳定元素的位移距离为可视区域高度的 25%，因此距离分数为 0.25。
所以，在这个示例中，影响分数是0.75 ，距离分数是0.25 ，所以布局偏移分数是0.75 * 0.25 = 0.1875 。
更多详细内容查看：布局偏移分数
FCP：First Contentful Paint 首次内容绘制
首次内容绘制 (FCP) 指标测量页面从开始加载到页面内容的任何部分在屏幕上完成渲染的时间。对于该指标，"内容"指的是文本、图像（包括背景图像）、<svg>元素或非白色的<canvas>元素。
在上方的加载时间轴中，FCP 发生在第二帧，因为那是首批文本和图像元素在屏幕上完成渲染的时间点。
虽然部分内容已完成渲染，但并非所有内容都已经完成渲染。这是FCP与LCP（旨在测量页面的主要内容何时完成加载）之间的重要区别。
TTI：Time to Interactive 可交互时间
TTI 指标测量页面从开始加载到主要子资源完成渲染，并能够快速、可靠地响应用户输入所需的时间。为了提供良好的用户体验，网站在普通移动硬件上进行测试时，应该努力将可交互时间控制在5 秒以内。
如需根据网页的性能跟踪计算 TTI，请执行以下步骤：
- 先进行首次内容绘制 (FCP)。
- 沿时间轴正向搜索时长至少为 5 秒的安静窗口，其中，安静窗口的定义为：没有长任务且不超过两个正在处理的网络 GET 请求。
- 沿时间轴反向搜索安静窗口之前的最后一个长任务，如果没有找到长任务，则在 FCP 步骤停止执行。
- TTI 是安静窗口之前最后一个长任务的结束时间（如果没有找到长任务，则与 FCP 值相同）。
下图将有助于您更直观地理解上述步骤：
长久以来，开发者为了追求更快的渲染速度而对页面进行了优化，但有时，这会以牺牲 TTI 为代价。
服务器端渲染 (SSR) 等技术可能会导致页面看似具备交互性（即，链接和按钮在屏幕上可见），但实际上并不能进行交互，因为主线程被阻塞或是因为控制这些元素的 JavaScript 代码尚未完成加载。
当用户尝试与看似具备交互性但实际上并非如此的页面进行交互时，他们可能会有如下两种反应：
- 在最好的情况下，他们会因为页面响应缓慢而感到恼火。
- 在最坏的情况下，他们会认为页面已损坏，因此很可能直接离开。他们甚至可能对您的品牌价值丧失信心或信任。
为了避免这个问题，请尽一切努力将 FCP 和 TTI 之间的差值降至最低。如果两者在某些情况下确实存在明显差异，请通过视觉指示器清楚表明页面上的组件还无法进行交互。
TBT：Total Blocking Time 总阻塞时间
TBT 指标测量 FCP 与 TTI 之间的总时间，这期间，主线程被阻塞的时间过长，无法作出输入响应。为了提供良好的用户体验，网站在普通移动硬件上进行测试时，应该努力将总阻塞时间控制在 300 毫秒以内。
每当出现长任务（在主线程上运行超过 50 毫秒的任务）时，主线程都被视作"阻塞状态"。我们说主线程处于"阻塞状态"是因为浏览器无法中断正在进行的任务。因此，如果用户在某个长任务运行期间与页面进行交互，那么浏览器必须等到任务完成后才能作出响应。
如果任务时长足够长（例如超过 50 毫秒），那么用户很可能会注意到延迟，并认为页面缓慢或卡顿。
某个给定长任务的阻塞时间是该任务持续时间超过 50 毫秒的部分。一个页面的总阻塞时间是在 FCP 和 TTI 之间发生的每个长任务的阻塞时间总和。
例如，请看以下这张页面加载期间浏览器主线程的图表：
上方的时间轴上有五个任务，其中三个是长任务，因为这些任务的持续时间超过 50 毫秒。下图显示了各个长任务的阻塞时间：
因此，虽然在主线程上运行任务的总时间为 560 毫秒，但其中只有 345 毫秒被视为阻塞时间。
| 任务持续时间 | 任务阻塞时间 | |
|---|---|---|
| 任务一 | 250 毫秒 | 200 毫秒 |
| 任务二 | 90 毫秒 | 40 毫秒 |
| 任务三 | 35 毫秒 | 0 毫秒 |
| 任务四 | 30 毫秒 | 0 毫秒 |
| 任务五 | 155 毫秒 | 105 毫秒 |
| 总阻塞时间 | 345 毫秒 |
