Web Performance Metrics 與 Core Web Vitals 簡介

Web Performance Metrics 與 Core Web Vitals 簡介

現代前端性能各個指標的具體含義和設計理念。

前言

我們都知道網站性能的重要性。 重要是重要,但是具體如何衡量和識別永遠是個非常發散、不容易說清的事情。 本文就將以業內重要會議上的分享為中心,分類詳細介紹主流語境下所有重要的數據指標定義。

歷史上,yslow 曾經作為互聯網開發的核心指標唯一評價工具,它的指標代表了核心指標。 之後逐步出現了 lighthouse 等種種新工具平臺和新檢測模式。 經過幾十年發展已經有眾多各式各樣的性能工具,對應的指標也趨於通用。 具體如何評價指標本身的代表性也逐漸成為問題,需要關注。

到了 2018 年,Google 在 I/O 大會上提到,75% 的用戶認為頁面的載入速度,是決定他們交互體驗的首要因素[1]。 Ire Aderinokun (Google Web Expert) 在 2020 年 #PerfMatter 的分享上說,「一旦頁面載入時間超過 5s,使用者就有 90% 的可能放棄它。 ”[2]

所以,到底如何準確衡量網站的性能?

根據 Google 在 web.dev 上公佈的數據,他們認為以使用者為中心的性能指標,應該能回答以下四個問題[3]:

web.dev 是 Google Developer 提供的開發者社區,裡面主要提到了一下列出的諸多類型的數據指標。

  1. 是否發生? 導航是否成功啟動? 伺服器是否有回應?
  2. 是否有用? 是否已渲染可以與用戶互動的足夠內容?
  3. 是否可用? 用戶可以與頁面交互,還是頁面仍在忙於載入?
  4. 是否令人愉快? 交互是否順暢而自然,沒有滯後和卡頓?

後文將介紹各性能指標如何回答上述問題,從而反應網站性能的,以及 Google 在提升網站性能上的努力 —— 推廣 Core Web Vitals。

第一部分,Performance Metrics

為了回答上述四個問題,Google 提出了一系列的性能指標。 根據上述的思考原則,我們把這些指標分為了四類,分別代表一次訪問被使用者感知的四個階段的具體表現。

(1) 是否發生?

當使用者訪問一個網站的時候,關心的第一個問題永遠是"是否發生"——瀏覽器是否成功地把我的請求發送出去,而伺服器是否已經知道並開始處理我的請求?

TTFBFPFCP 就是回答這些問題的指標。

1. TTFB (Time to First Byte)

首位元組到達的時間點。

2. FP (First Paint)

首次繪製,標記瀏覽器渲染任何在視覺上不同於導航前屏幕內容的時間點。

3. FCP (First Contentful Paint)

首次內容繪製,標記瀏覽器渲染來自 DOM 第一位內容的時間點,內容可能是文本、圖像等元素。

TTFB、FP 和 FCP 這些指標標記出瀏覽器開始繪製內容的時間點,這些時刻等同於告訴使用者:"瀏覽器已經開始處理伺服器的返回了,你的請求已經發生了!"


(2) 是否有用?

當用戶確定自己的請求發生了后,就會開始關心第二個問題:"是否有用? ”

例如,使用者在使用天氣應用,在確定頁面有反應了后,就開始關心,什麼時候能展現有用的內容,從而得知今天的天氣。

FMPLCPSI 就是回答這些問題的指標。

1. FMP (First Meaningful Paint)

首次有效繪製,是指首次繪製對使用者有用內容的時間點。 有用的內容,是指 Youtube 上的視頻;Twitter 上的推文;天氣應用中的天氣預測...... 這些內容或元素,也被稱為主角元素(Hero Elements),能夠向使用者提供有用的內容。 但是這些元素難以界定,所以後來用 LCP 來取代 FMP。

2. LCP (Largest Contentful Paint)

最大內容繪製時間,計算從頁面開始載入到使用者與頁面發生交互(點擊,滾動)這段時間內,最大元素繪製的時間,該時間會隨著頁面渲染變化而變化,因為頁面中的最大元素在渲染過程中可能會發生改變。

3. SI (Speed Index)

速度指標,填充頁面內容的速度,取開始載入到最後完成渲染,每一時刻頁面未完成度的積分。 頁面的視覺完成度(visually complete)是基於 SSIM(Structural similarity Index) 計算的。

計算方式

例如下面的例子中,假設頁面渲染在 6 幀中完成,每幀 500 ms,其中每幀的頁面完成度分別為 0%,10%,30%,60%,90%,100%,計算得到 SI = 500 + 450 + 350 + 200 + 50,SI 的數值越低證明頁面被填充的越快,使用者的體驗越好。

LCP 標記出瀏覽器繪製最大內容的時間點,並默認認為頁面中最大的元素是對使用者最有用的內容。 LCP 試圖標記出使用者是在什麼時刻得到有用內容的,而越早得到有用內容,用戶的體驗自然就越好。 SI 反應出填充頁面內容的速度。 例如下圖,雖然都是最後時刻填充完內容,但顯然,上面會有種頁面載入更快的感覺。


(3) 是否可用?

在使用者得到了有用的訊息後,使用者就會基於得到的訊息作出反應,這就是頁面「是否可用? "例如看到了新聞後,想要評論;知道了天氣後,想要轉發提醒朋友等等。 TTI、FID、TBT 就是回答這些問題的指標。

在解釋這些指標之前,我們先要理解為什麼頁面有時候不能及時響應使用者。

1. Long Tasks

時任務。 瀏覽器是單線程,所有任務會被添加到主線程的佇列中逐個執行。 如果有任務耗時過長,主線程就會被阻塞,其他任務就只能等待,包括那些由使用者交互產生的任務,從而無法及時回應使用者。 根據 Jakob Nielsen 的研究 Response Times: The 3 Important Limits [4],頁面應該在 100 ms 內回應使用者輸入,否則就會被使用者認為卡頓。 要實現小於 100 ms 的回應,單個任務必須在 50 ms 內完成。 這樣即使使用者的輸入行為發生在某個任務剛開始的時候,並且耗時 50 ms,在這個任務結束後,主線程仍有 50 ms 時間來回應使用者輸入,總回應時間在 100 ms 內。

通過 Chrome DevTools 或 Long Task API 能方便地發現這些耗時任務。

2. TTI (Time to Interactive)

可交互時間,用於標記頁面已進行視覺渲染並能可靠回應使用者輸入的時間點。 頁面可能會因為多種原因而無法回應使用者輸入,例如頁面元件運行所需的 Javascript 尚未載入,或者耗時較長的任務阻塞主線程。 TTI 指標可識別頁面初始 JavaScript 已載入且主線程處於空閒狀態(沒有耗時較長的任務)的時間點。

3. TBT (Total Blocking Time)

總共阻塞時間,計算的是從 FCP 到 TTI 之間,主線程阻塞的總時間。 阻塞時間是指單次任務佔用主線程超過 50 ms 的部分。

計算方式

例如下面的例子是頁面載入過程中從 FCP 到 TTI 之間主線程的運行情況,一共執行了 5 個任務,分別耗時 250 ms,90 ms,35 ms,30 ms,155 ms,其中 3 個任務耗時超過 50 ms,將它們阻塞的時間累加起來 250 - 50 + 90 - 50 + 155 - 50 = 345 ms,得到 TBT。 越低的 TBT 證明頁面的有用性,可交互性越好。

4. FID (First Input Delay)

首次輸入延遲,指使用者首次輸入到頁面回應的時間。 我們都知道第一印象的重要性,網站亦是如此。 首次輸入延遲會成為使用者對網站很重要的第一印象,決定使用者有可能成為忠實使用者或者棄之而去。 值得注意的是,FID 僅關注使用者離散的操作,如點擊,輕擊,按鍵等,其他交互如滾動和縮放,並不是 FID 關注的,因為通常流覽器會用一個單獨的線程來處理它們。


(4)是否令人愉快?

先來舉個不愉快的例子。

在這個例子中,你本想點擊按鈕 B,頁面突然發生偏移,你不幸點到了按鈕 A。 "是否令人愉快?" 是使用者在整個應用使用過程中都會發生的問題,它不僅包含之前說的 Long Tasks,要包含一些不符合預期的佈局偏移,即 CLS。

1. CLS (Cumulative Layout Shift)

累計佈局偏移。 測量在頁面的整個生命週期中發生的每個意外的樣式移動所造成的佈局偏移分數的總和。

計算方式

某次佈局偏移分數 = 影響分數 * 距離分數。 前一幀和當前幀的所有不穩定元素的可見區域的並集(占視口總面積的一部分)是當前幀的影響分數。 例如下圖中,有一個元素在一幀中佔據了視口的一半。 然後,在下一幀中,元素下移視口高度的 25%。 紅色的虛線矩形表示兩個幀中元素的可見區域的並集,在這種情況下,其為總視口的 75%,因此其影響分數為 0.75。

距離分數是任何不穩定元素在框架中移動的最大距離(水平或垂直)除以視口的最大尺寸(寬度或高度,以較大的為準)。 例如下圖中,最大的視口尺寸是高度,並且不穩定元素移動了視口高度的 25%,這使得距離分數為 0.25。 所以,在此例中,影響分數為 0.75,距離分數為 0.25,因此佈局偏移分數為 0.75 * 0.25 = 0.1875。

不知道你有沒有意識到一個問題,什麼叫意外的偏移? 如何區分下面兩種情況,前者是意外的偏移,後者則是點擊搜索按鈕展開,是符合預期的。 所以 CLS 在計算過程中會忽略使用者交互後 0.5s 內的佈局偏移;同時 CLS 也會忽略動畫,忽略 transform 的變化[5]。


第二部分,Core Web Vitals

在第一部分中,我們瞭解了 1 個概念(Long Tasks)和 10 個指標的定義及部分計算方式,但現在的你怕是想不起來幾個了 。 都不記得有哪些性能指標的我們,有如何依據這些指標來提升網站性能呢。 為此,Google 對眾多的指標進行了取捨,提出了 Core Web Vitals。

什麼是 Core Web Vitals?

概括來說:

  1. 是 Google 為了提升網路整體性能的努力;
  2. 是 Web Vitals 的子集,其核心基礎指標 LCP,FID 和 CLS;
  3. 是未來網頁排名演算法中新的因數;

今年 5 月,Google 在 Chromium Blog 中提出的 Web Vitals,旨在提供統一的指標來量化使用者在網站上的體驗,囊括了之前在性能指標上的努力。 同時,Google 認為不用每個人都成為網站性能方面的專家,大家只需要關注那些最核心最有價值的指標即可,於是提出了 Core Web Vitals,它是 Web Vitals 的子集,包含 LCP(Largest Contentful Paint),FID(First Input Delay) 和 CLS(Cumulative Layout Shift)。

為什麼是 LCP, FID 和 CLS?

  1. 具有代表性;
  2. 簡單,容易理解;
  3. 可以精確測量;

因為這三者分別從不同的角度(載入速度,交互性和視覺穩定性)反應了用戶的體驗。 LCP 測試載入速度的體驗,頁面最主要的內容何時呈現;FID 測試交互上的體驗,使用者第一次輸入後經過多久得到了回應;CLS 測試視覺穩定性上的體驗,有多少內容發生了意外的偏移。 因為它們可以精確測量,所以可以對它們分級,如何是好,如何是需要提升,如何又是差。

Google 用 75 分位來代表網站某一指標的整體結果 [6]。 例如,網站 75% 的訪問中,LCP 都小於 2s,那麼網站的 LCP 指標就是好;相反,網站超過 25% 的訪問中,FID 都超過 300ms,那麼網站的 FID 就是差。

為什麼是≤ 2500ms, ≤ 100ms, ≤ 0.1?

首先基於 Google 的調查研究The Science Behind Web Vitals blog.chromium.org/2020/),滿足上述標準的網站,是能給用戶帶來良好的體驗。

其次,這些指標也是可以達到的,在推出這些指標和閾值之前,已經基於CrUX (Chrome User Experience Report) 的數據發現有10%的網站是能滿足上述指標。

工具及周邊

Google 正大力地推廣 Core Web Vitals,除了在 I/O '20 上賣力的宣傳,在 Webmaster 上聲明會將 Core Web Vitals 納入網頁排名演算法中,還提供了一系列的工具來幫助開發者基於這些指標去測量自己的網站。

  1. 你可以先用 Search Console 新的 Core Web Vitals 報告去查看自己網站的性能情況。
  2. 如果發現自己的網站有些問題的話,可以用 PageSpeed Insights 去定位網站的性能問題。
  3. 然後你可以先在實驗室本地環境,用 LighthouseChrome DevTools去測量頁面,得到具體的指引去修復性能問題。 或者用 Web Vitals Chrome extension 在桌面端即時看到自己頁面的 Core Web Vitals。
  4. 如果你需要 Core Web Vitals 的 dashboard,可以使用更新後的 CrUX(Chrome User Experience Report) Dashboard 或者使用新的 Chrome UX Report API 來獲得真實數據。
  5. 缺少指引? web.dev/measure 可以測量你的頁面,基於 PSI(PageSpeed Insights) 數據,給你相關的建議。
  6. 最後,引入 Lighthouse CI 來確保每次反覆運算都沒有使你的 Core Web Vitals 倒退。

參考文檔

[1]

[2]

[3]

[4]

[5]

[6]

[7]

歡迎關注「 位元組前端 ByteFE

簡歷投遞聯繫郵箱 [email protected]

頁面載入性能之Web Vitals

我給網站做了一場性能手術