Lighthouse Metrics:以使用者為出發點來探討效能的指標

Lighthouse Logo

本文說明 Lighthouse 以使用者為出發點來探討效能的指標。


網站的「效能」很重要 - 這簡直是網站開發與維運過程中最常聽到的老生常談之一,但當我們談到「效能好」或「速度快」時,我們到底指的是什麼?

效能可能和以下這些有關…

以上都在談論效能所造成的影響,但考慮的是完全不同的東西…因此,當談到「效能」時,明確的指出所要評估的「指標」能讓我們更聚焦在要解決的問題上。


過去常用 load event 來衡量網站效能,雖然 load event 很明確的指出網頁生命週期的載入的這個時刻,但卻無法表達使用者在乎的細節。例如,當一個頁面載入時,伺服器很快的回應,讓這個頁面很快的將所有所需資源載入完成,而觸發 load event;而此頁面的主要內容可能是由另一支 API 取得的,可是伺服器回應得很慢 XD 此時使用者雖然可以看到頁面載入完成卻無法看到最重要的部份…這樣的狀況對使用者來說就是效能很差,不過就無法用 load event 來做測量。

那麼,以使用者的觀點來看,所謂的效能是意味著哪些狀況呢?

關於測量使用者對於效能感知的指標,有以下幾種

針對以上的指標,一方面是發現沒有任何單一指標可以含括效能相關的議題,另一方面也指出使用者針對效能所考量的各種面向。因此,Lighthouse 針對以使用者觀點的測量效能方式,提出了一些衡量的指標以供參考(目前不包含 runtime responsiveness)。

在看指標之前,先來看 RAIL。

RAIL

RAIL 是一個以使用者為中心、可用來衡量效能的模型。這個模型將使用者的行為分為幾種類型,並針對這些類型定義改進效能的目標。也就是說,RAIL 分別代表 app 生命週期的不同階段 - Response、Animation、Idle 和 Load,使用者對於這些階段皆有不同的期待,因此對於改善效能的目標就是依據使用者對於這些階段所能接受的延遲時間來定義的。

RAIL 的定義如下

RAIL

圖片來源

舉例來說,使用者點擊按鈕後會是這樣的狀況…

RAIL

圖片來源

說明

Metrics

Lighthouse 針對以使用者觀點的測量效能的指標,有以下幾種:

以下分別說明,並且為了確保此 App 的大多數的使用者能達到這個目標,評估桌上機和行動裝置的第 75 個百分位(註 1)必須要能達到此這個標準。


我們在閱讀 Lighthouse 的報告的時候,可能會困惑這些指標與最後所得到的分數是什麼關係…

下圖是 Lighthouse 的效能測量結果。

Lighthouse 效能測量結果

指標和分數有什麼關係呢?佔比是這樣的…

這是衡量了使用者的角度後所得到的佔比,後續的實驗可能會再更新指標或比例。若想知道更多指標與分數的資訊,可參考這裡

First Contentful Paint (FCP)

First Contentful Paint (FCP) 是測量感知載入速度的一個指標,FCP 是指頁面載入了使用者可在螢幕上看到的任何元素的時間點,快速的 FCP 確保使用者不是空等。「任何元素」可以是任何的文字、圖檔或非白色的背景色。

什麼是好的 FCP?

根據 RAIL 的原則,好的 FCP 必須小於 1 秒。

Largest Contentful Paint (LCP)

Largest Contentful Paint 是測量測量感知載入速度的一種指標,實際上是測量頁面主要內容(或稱最大面積)內容已載入的所需時間,這個計算時間會在使用者開始與頁面互動時結束。快速的 LCP 能讓使用者確保該頁對他們是有用的。

範例如下圖這個頁面載入的流程,一開始畫面是什麼都沒有的,然後出現了 loading icon 暗示使用者網站仍在持續載入資源,接著出現了第一個元件,最後顯示完整的網頁內容。

FCP, LCP

因此…

對照實際狀況來看…以這個網頁為例,從 Chrome DevTools 的 Performance 標籤頁的 timeline 可以看到標記,點選「LCP」可以圈出到底是指哪一塊 DOM 元素和顯示相關資訊,例如:節點類型、timestamp 等。

如圖,認定主要內容是由 <p> 所包含的文字片段 To provide a good user experience...,LCP 時間是 763 ms,

Timeline

這裡可以注意幾點…

什麼是好的 LCP?

First Input Delay (FID)

First Input Delay (FID) 是測量載入互動性,實際上是測量使用者第一次與頁面互動(例如:點某個連結、點某個按鈕等)到瀏覽器有空回應的時間,也就是測量接收到 input event 與 main thread 狀態為 idle 的這段間隔時間的值(又可稱為 input delay 或 input latency)。較低的 FID 可讓使用者更快確認此頁面是否可用。

注意…

TTI, FCP, FID

如上圖所示,當頁面發出要求資源的網路請求時(灰色區塊),在檔案下載完畢後,瀏覽器的 main thread 都需要花不等的一段時間來做處理(藍色區塊,每個區塊視為一個 task)。

當 main thread 在花時間處理處理這些 task 時,真的是非常忙碌的,若此時使用者嘗試和頁面元件互動,像是點某個按鈕,則必須等到這個 task 結束後才能做出反應、開始處理,這一段等待的時間即是前面所說的 FID。

什麼是好的 FID?

Time to Interactive (TTI)

Time to Interactive (TTI) 是測量載入互動性,實際上是測量頁面載入後,使用者可與瀏覽器互動並能給予回應的時間,也就是測量在長時間工作結束後、main thread 可 idle 五秒 (quiet window) 前的這段時間。見上圖。所謂 quiet window 是指沒有長時間 (> 50 ms) 的 task,且沒有超過 2 個 GET 網路請求。這也是想測試 RAIL 的「R,反應」,意即此頁面是否能與使用者互動。

TTI, FID

什麼是好的 TTI?

TTI 必須低於 5 秒才是好的。

Total Blocking Time (TBT)

Total Blocking Time (TBT) 是測量載入互動性,實際上是測量 main thread 被 long task (> 50ms) block 的時間,也就是只算「超過 50ms」的部份。

如下圖所示,這裡有 5 個 task,其中有 3 個 task 的執行時間超過 50ms。

TTI

計算超過 50ms 的部份,也就是被 block 的時間,因此 TTI 為 200 + 40 + 105 = 345 ms。

TTI

圖片來源

什麼是好的 TBT?

Cumulative Layout Shift (CLS)

Cumulative Layout Shift (CLS) 是用於測量頁面視覺的穩定度,實際上是測量頁面存活週期間,每個可見元素移動位置的分數的總和。它有助於量化使用者經歷意外的版位移動的頻率,較低的 CLS 有助於確保頁面是令人愉悅。

若頁面有太多元素處於不穩定的狀態,意即不斷的位移,可能導致使用者難以對正確的元件互動(例如:按錯按鈕、無法正確理解目前頁面呈現的資訊等)。

頁面有不預期的移動的元素往往是因為

以上問題可能與使用的測試圖片可能已在開發者環境的被快取起來、API 回應速度不同有關,而導致這個問題在在開發環境與真正客戶所使用的正式產品環境往往差異很大,因此需要使用 CLS 來協助評斷這種畫面元素不預期移動的頻率,以期改善這個問題。


要怎麼計算 Cumulative Layout Shift 呢?公式是這樣的…CLS = impact fraction * distance fraction,範例如下。

Cumulative Layout Shift, CLS

如上圖所示,使用者一開始在畫面上看到的狀態(如圖左),接著載入廣告(如圖右),並將原本顯示圖文的區塊往下擠,因此…

也就是說,得到 CLS = impact fraction * distance fraction = 2/3 * 1/3 = 2/9 ~ 0.22

關於 CLS 常見的解法是使用 CSS transform 而非改變 width、height、position 的值。

什麼是好的 CLS?

Speed Index

Speed Index 是測量頁面在視覺上的流暢性,實際上是測量頁面在載入過程中,視覺上變化的速度,愈低的 Speed Index 表示過程愈流暢。

計算方式如下…

Speed Index Formula

圖片來源

這個公式算的是反向的面積…其中 x 軸是經過的毫秒數,y 軸是完成百分比

Speed Index

圖片來源

如下圖所示,若有一頁面 Page 1 的載入過程是從一開始的緩慢(約 10%)突然進展到 50% 再快速到達 100%;相較於 Page 2 是漸進的持續載入,其中每一格代表 1 秒,約 10 秒完成載入。

Speed Index

經計算後…

Page 1 的 6500 > Page 2 的 5000,因此 Page 2 的載入過程較佳、較為流暢。

什麼是好的 Speed Index?

Speed Index 應小於 1000。

新制的算法是換算為秒數,也就是

總結

目前 Lighthouse 預設環境是 Moto G4。

# Metrics 縮寫 定義 Good Needs improvement Poor
1 First Contentful Paint FCP 測量感知載入速度,實際上是測量頁面載入使用者可在螢幕上看到的任何元素的所需時間。 < 1 秒    
2 Largest Contentful Paint LCP 測量感知載入速度,實際上是測量頁面最大面積內容已載入的所需時間。 < 2.5 秒 2.5 ~ 4 秒 > 4 秒
3 First Input Delay FID 測量載入互動性,實際上是測量使用者第一次與頁面互動到瀏覽器有空回應的時間,也就是測量接收到 input event 與 main thread 狀態為 idle 的這段間隔時間的值。 < 100 ms 100 ~ 300 ms > 300ms
4 Time to Interactive TTI 測量載入互動性,實際上是測量頁面載入後,使用者可與瀏覽器互動並能給予回應的時間,也就是測量在長時間工作結束後、main thread 可 idle 五秒 (quiet window) 前的這段時間。 TTI < 5 秒    
5 Total Blocking Time TBT 測量載入互動性,實際上是測量 main thread 被 long task (> 50ms) block 的時間。 < 300 ms 300 ~ 600 ms > 600ms
6 Cumulative Layout Shift CLS 頁面視覺的穩定度,實際上是測量頁面存活週期間,每個可見元素移動位置的分數的總和。 < 0.1 0.1 ~ 0.25 > 0.25
7 Speed Index   頁面在視覺上的流暢性,實際上是測量頁面在載入過程中,視覺上變化的速度。 Speed Index 應小於 1000;新制:< 4.4 秒 新制:4.4 ~ 5.8 秒 新制:> 5.8 秒

備註

# Real User Monitoring Synthetic Monitoring
分類 passive monitoring active monitoring
監測方式 監測真正的使用者在操作網站功能的效能並搜集與分析資料 模擬使用者的行為來測試網站的效能
目的 了解長期走向 診斷與解決短期問題
範例或產品 Stackify Lighthouse
優點 全方位監測;能找出真實的困境 測試單純,能定期追蹤比較;可指定特定時間環境;可用於非正式環境
缺點 需要流量;缺乏測試基準;只能用於正式環境 並非真實狀況;可預測的固定測試情境而難以發覺未知問題
對象 管理者 技術人員
擬真度

參考資料


(2020/09/11 更新) 公司內部小分享,補上投影片


comments powered by Disqus