【Debug】 你所不知道的各种前端Debug技巧系列Performance - Web Vitals---第19天

概览

Web Vitals 是由Google 分析大量使用者资料后，用来量化网站使用者体验的指标，藉由测量Web Vitals 分数让开发者能更有方向的优化网站体验，尤其是Core Web Vitals。

Core Web Vitals

Core Web Vitals 是由Google 定期选出，在三种不同面相中最具代表性的使用者体验指标，而目前的Core Web Vitals 分别是：

Largest Contentful Paint (LCP) – 载入速度
First Input Delay (FID) – 互动性
Cumulative Layout Shift (CLS) – 稳定性

LCP

lab、field

最大内容绘制（LCP） 是「载入速度」的代表，代表页面中最大的图片、影片预览图、文字等等，由于各个元素绘制的速度不同，LCP 可能随时间改变。

比起load或DOMContentLoaded事件，LCP更贴近使用者感受到页面内容已经载入完成的时间。

判断依据

只有完全绘制在可视区域的元素才会被算入LCP，每当页面出现一个比当前LCP 更大的元素就会取代为新的LCP，直到使用者开始和网页互动为止。

取自 https://web.dev/lcp/，绿色元素是读取过程不断变化的LCP

FID

field

首次输入延迟（FID）为「可用性」的代表，大大的影响使用者对网页的第一印象，大家一定都有刚载入某个网页时，按钮或连结怎么点都没有反应的经验吧？

判断依据
使用者第一次点击按钮、连结或和input、checkbox等等元素互动时，元素反映使用者动作的延迟，具体来说是触发输入事件到主线程下一次空闲（也就是终于有空来执行Event listener）的时间。

取自 https://web.dev/fid/，FCP同样也是影响第一印象的重要指标，另外图中也示意了TTI的区间。

CLS

Lab、Field

累计排版位移（CLS）是「稳定性」的代表，网页中载入过程中可能因为元素载入速度不同造成元素位移，例如图片读取完毕时撑开了元素上方的空间等等，最恼人的就是正准备点击某个按钮时因为元素位移点到了其他按钮。

判断依据
CLS的计算公式为：影響範圍（impact fraction）* 移動距離（distance fraction），也就是元素位移前后位置的联集占萤幕空间比例乘上元素移动距离占萤幕比例，并累加所有值。

另外在使用者互动500 毫秒内的CLS 不会被计入，例如点击展开元素，因为这些CLS 是可预期的。

取自 https://web.dev/cls/，强迫购买的概念？

Web Vitals

以下是除了Core Web Vitals 以外的指标，前二者与LCP 较相关，后二者则和FID 有关，可作为优化Core Web Vitals 的考量依据之一。

FCP

lab、field

First Contentful Paint 为网页绘出第一个图片、文字等内容的时间。

TTFB

lab、field

Time to First Byte 关系到网路速度、Server 处理时间，具体计算是从使用者发出Request 到接收到第一个Byte 的时间。

TTI

lab

Time to Interactive 代表完全可以开始和网页互动的时刻，具体计算是从FCP 到最后一个Long task 结束的时间，Long task 是指主线程中执行超过50 毫秒的Task，最后一个Long task 代表5 秒内没有其他Long task 且当时没有三个以上的GET 请求。

TBT

lab

由于主线程在TTI 之前还是有零星的空闲，Total Blocking Time 用来计算从FCP 到TTI 之间会使用者互动时无法立即回应的区间总和，实际计算是把所有Long task 超过50 毫秒部分加总。

取自 https://web.dev/tbt/，例如最左边的Task执行了250 ms，就有200 ms的Blocking time。

Why 50 ms?

由于使用者和元素互动时执行Event Listener 也需要时间（估计不超过50 ms），且页面的反应时间在100 毫秒内使用者才不会有卡住的感觉，因此超过主线程上超过50 ms 的Task 越长越多，卡住使用者的机率越高。

指标测量方式

Web Vitals 的测量环境分为两种，可以看到刚才提及的各个指标下方都有标注能在哪些环境测量：

in the lab – 开发时的稳定环境来模拟页面载入
in the field – 真实使用者的载入和互动

In the lab

一方面是网页正式上线前，肯定没有使用者资料，且开发环境才能稳定的测量各个效能指标，藉由分数比较优化前后的差异，并在上线前尽可能提高分数。

In the field

由于网页就是给使用者看的，最真实的效能资讯就是来自使用者，使用者的设备、网路都不同，甚至是收到的广告、额外的插件也会影响等等，在开发环境难以模拟。

Score

Good、Poor 的判定方式是看PR75 的使用者落在哪个区间，假设一个页面中PR75（也就是秒数较少的75% ）的使用者LCP 低于2.5 秒就是Good，若大于4 秒就是Poor 。

测量工具

Core Web Vitals 的测量工具有很多种，分别有其适用之处，以下简单说明各个工具的特色以及适用的环境：

Lab & Field

PageSpeed Insights
输入网址就能测量指标，测量结果来自Lighthouse 和Chrome UX Report，可以同时比较Lab 和Field 的使用体验报告。

Web Vitals Extension

Chrome Extension，安装后方便及时测量指标。

Web Vitals Library

用Web Vitals 提供的JavaScript library 客制测量工具。

Field

Chrome UX Report
来自真实资料，可透过图表比较不同时间的指标变化，也可用网路、设备、国家来分类。

Search Console
以页面为单位测量指标，可以针对效能较差的页面先做优化。

Lab

Chrome DevTools & Lighthouse
直接在开发环境测量指标，由于没有真实使用者，以TBT代替FID。
另外可以参考Score calculator看看Lighthouse是怎么计算分数的。

WebPageTest
一样以TBT 代替FID，另外会以多种环境如设备、地理位置等等来测量网站，提供非常丰富的资讯。

如何影响SEO

网站使用体验和一直是SEO 计算的重点，利用Web Vitals 量化使用者体验后，开发者在提升使用者体验的部分有了更明确的改进方向。

而其他影响SEO 的重点还有行动装置相容性、网页安全性、HTTPS、侵入式广告、弹窗等等。