iT邦幫忙

2024 iThome 鐵人賽

DAY 20
2

https://ithelp.ithome.com.tw/upload/images/20241004/20152073YPtGTSIRly.png

前言

既然我們有監控前端應用程式的需求,是因為我們需要知道我們的網站是否能夠提供良好的使用者體驗,其中佔比最大的就是效能問題。而我們可能都了解過效能需要如何改善,但卻比較少了解他們被制定的依據,因此在本章中我們會探討效能是怎麼被定義的,以及定義後又如何被測量。在網頁中最廣為人知的效能指標就是 Web Vitals,因此以下會以 Web Vitals 為主軸,介紹效能指標的定義與測量。

Core Web Vitals 是什麼?

https://4sight.group/wp-content/uploads/2022/01/core-web-vitals.jpg

Core Web Vitals 是 Google 推出的一個計劃,目的是為網站開發者提供一組標準,用來衡量網站是否提供良好的使用者體驗。這些指標注重於使用者實際感受到的網頁體驗,像是頁面加載的速度、是否可以順利與網站互動,以及網站的視覺穩定性。簡單來說,Core Web Vitals 嘗試回答幾個核心問題:網站是否加載得夠快?網站能否順暢操作?頁面元素會不會突然移動,影響使用體驗?

這些指標不只是衡量效能,它們也被 Google 搜尋引擎納入排名考量,這意味著網站開發者優化這些指標,除了提升使用者體驗,也能讓網站在搜尋結果中有更好的排名。因此,專注於提升 Core Web Vitals 成為許多開發者的重要任務,因為它可以同時帶來技術和業務上的雙重效益。

如何定義

對網站來說,越好的效能代表速度越快,使用者體驗越好。但『快』這件事,對於不同的使用者來說,感受是不一樣的。除此之外同一個網站可能因為不同的網路環境,或是不同的裝置,都會有不同的效能表現。因此需要定義出一套標準,來衡量網站的效能。

一般測量網站的效能是通過 load event 來評估,但這種方法並不能準確反映使用者的實際體驗,例如,一個頁面可能很快「加載」完成,但實際上延遲顯示內容,使得使用者實際感受到的加載時間比加載事件觸發的時間要長。

💡TIP
load event 是瀏覽器在載入完所有資源後會觸發的事件,通常用來表示頁面已經加載完成。可使用 addEventListener('load', () => {})window.onload = () => {} 監聽。

所以 Chrome 團隊定義了幾個效能指標必須反映的問題:

https://web.dev/static/articles/what-is-speed/image/image-speed-metrics-534ca7f892b1d_856.png

  • 是否正在發生? 這關於網頁導航是否成功開始,以及伺服器是否已經做出回應。
  • 是否有用? 評估是否已經渲染了足夠的內容,讓使用者可以開始與頁面互動。
  • 是否可用? 判斷使用者是否能夠與頁面互動,或者頁面是否因為加載或處理中的任務而變得無法使用。
  • 是否令人愉悅? 考慮使用者與頁面互動時,是否感到流暢自然,沒有延遲和卡頓。

指標類型

在了解效能評估的基本方法以及指標需要反映的問題,需要更具體的定義出這些問題與實際的網頁行為,或是網頁會與使用者的那些感知相關。這其中涵蓋多個面向,沒有單一指標可以全面代表網站的效能。因此,我們可以從以下幾個角度來理解網站的效能表現:

  • 感知載入速度:衡量頁面載入並將所有視覺元素渲染到螢幕上的速度(FCP)。
  • 載入回應:評估頁面載入後,執行必要的 JavaScript 程式碼,使元件能夠快速回應使用者互動的效率。
  • 執行階段回應:衡量頁面載入後,頁面對使用者互動的回應速度(FID)。
  • 視覺化內容穩定性:觀察頁面上的元素是否會在使用者未預期的情況下移動,可能會干擾他們的操作(CLS)。
  • 流暢度:確保過渡和動畫以一致的幀率渲染,並在狀態間平順過渡。

Web Vitals 有哪些指標?

依據上述指標類型 Core Web Vitals 目前所包含三個主要指標:LCP、INP(替代了 FID)和 CLS。此外,還有一些其他的 Web Vitals 指標,如 TBT、TTFB、FCP 等。每項指標都會評估不同使用者體驗的層面:LCP 衡量感知載入速度,會在頁面主要內容載入完成時,於網頁的載入時間軸上標示出具體時間點;FID 主要評估回應速度,量化使用者在首次與網頁互動時的體驗;CLS 測量視覺穩定性,量化頁面內容在顯示過程中發生意外版面移動的情況;INP 則是一個新的指標,用來衡量整個頁面生命週期內的互動效能,反映使用者與頁面進行多次互動時的整體回應表現。

指標分級門檻

https://ithelp.ithome.com.tw/upload/images/20241004/20152073X13nLIWHLE.png

每個指標的定義都是經過一系列的感知研究,並根據 CrUX(Chrome 使用者體驗報告)的數據來制定標準,以確保其具備可達性。效能評估被分為「良好」、「需要改進」和「不良」三個門檻等級。雖然網頁通常會追求速度越快越好,但人類對於使用體驗的感知非常複雜,其中包含許多不可控因素的干擾,甚至可能存在不同標準之間的衝突。因此,Google 在 2020 年為 Core Web Vitals 指標設定門檻時,特別強調了以下幾個重點,以提供最佳的使用者體驗衡量方式:

  • 高品質的使用者體驗:門檻的主要目標是確保網站達到這些門檻後,可以提供高品質的使用者體驗。門檻的設定基於人類感知和人機互動 (HCI) 研究,並且依據實際數據來選擇合理的範圍,而不是只使用單一固定數值。
  • 現有網站的可達性:這些門檻必須是現有網站能夠達成的。因此,儘管零毫秒的加載時間是理想的,但由於技術限制,不可能完全達成。Google 會透過 Chrome 使用者經驗報告 (CrUX) 的數據,來做為門檻分級的依據。
  • 門檻的衝突與折衷:在設定門檻時,某些標準會相互衝突。例如,確保門檻具備一致性與確保良好的使用者體驗之間有時需要取得平衡。Google 的策略是選擇最符合多個標準的門檻,而不是尋求完美的數字。

綜合以上重點,Core Web Vitals 在制定各指標門檻時,對於【良好】標準要求至少有 10% 的網站可以達到目標秒數,而表現最差的 10-30% 會被歸類為【不良】。針對單個網站,評估標準是基於所有瀏覽量的第 75 百分位數作為門檻依據。

為什麼是第 75 個百分位數?

💡第 75 百分位數
第 75 百分位數 是指在所有網頁瀏覽次數中,排在前 75% 的瀏覽經歷的效能。
例如,對於 LCP(Largest Contentful Paint)這個指標來說,如果第 75 百分位數的 LCP 值是 2 秒,表示 75% 的瀏覽都能在 2 秒內完成主要內容的載入,這被視為「良好」的表現。反之,如果第 75 百分位數的 LCP 值是 5 秒,表示大部分瀏覽需要 5 秒才能載入主要內容,這樣就會被分類為「不良」。

選擇第 75 百分位數作為標準的原因主要基於兩個條件:

  1. 確保大多數瀏覽經歷符合目標效能:選擇越高的百分位數,涵蓋更大範圍的使用者體驗,提供更具代表性的效能評估。例如選擇第 75 百分位數,即 75% 的瀏覽經歷達到了某個效能標準或更快。
  2. 減少離群值的影響:使用第 95 百分位數,有 5 % 異常的數據就可能顯著影響結果;而第 75 百分位數則需要 25 % 異常值才會顯著影響結果。

假設我們有一個網站,記錄了100次頁面載入時間(單位:秒)。這些時間大多數都在1-3秒之間,但有幾次由於網絡問題,載入時間異常地長。導致出現大量異常的 LCP 樣本,我們不希望這些異常樣本影響對網站效能的分類結果。

數據如下:
1, 1.2, 1.5, 1.7, 1.8, 2.0, 2.1, 2.3, 2.5, 2.7, ...(共90個介於1-3秒的值)...,
3.0, 10.0, 12.0, 15.0, 20.0

  • 使用第 75 百分位數:相當於第75個值,得到的結果(2.7秒)更能代表大多數使用者的實際體驗。
  • 使用第 95 百分位數:相當於第95個值,得到的結果(10秒)被少數這五個極端情況嚴重扭曲,無法準確反映大多數使用者的體驗。

然而這兩項標準需求是互相衝突的,因為百分位數越高,產生的值受到離群值影響的可能性也隨之增加,因此 Google 以 CrUX 做為資料來源,並根據每個指標在不同數值及裝置分析後,第 75 百分位數能夠在確保大部分訪問達到效能標準的同時,有效減少離群值對評估結果的影響,達成了兩個標準的平衡。

如何測量 Web Vitals?

基於上述所定義的問題,Chrome 團隊採用了兩種評估方法:Field 和 Lab。這兩種方法不是互相取代,而是相輔相成。我們在開發的時候,由於沒有真實的使用者可以給我們評估數據,所以必須依靠實驗室中的模擬網頁載入來為我們評估效能;而研究室中的測試雖然理論上是可行的,但不一定能反映所有使用者真實的網站體驗。且為確保良好的網站效能,通常建議兩者搭配使用,以便從不同角度獲得最完整的效能評估。

  • Field:在真實的使用者環境中收集數據,以模擬實際使用情況。
  • Lab:在受控的實驗室環境中收集數據,並使用工具模擬頁面載入。
  • 其他混合型工具:PageSpeed Insights (PSI)、Web Vitals Chrome 擴充功能。

而針對這兩個評估方法有各自有非常多樣化的評估工具,以下進行分類介紹:

Field

是來自實際使用者訪問網站時的效能數據,反應了使用者的真實裝置、網路條件和地理位置。Field 資料代表了不同使用者體驗的數據分佈,並不僅僅是一個單一數值。這些數據通常來自 CrUX 報告或 Real User Monitoring (RUM) 工具,更真實地反應了網站的效能。常用的 Field 測量工具包括:

  • Chrome 使用者體驗報告
  • Search Console (網站體驗核心指標報表)
  • web-vitals JavaScript 套件

(一) Chrome 使用者體驗報告 ( CrUX )

https://developer.chrome.com/static/docs/crux/dashboard/image/crux-dashboard_856.png?hl=zh-tw

CrUX 是 Google 提供的公開數據集,收集全球數百萬網站的真實 Google Chrome 使用者數據,反映網站的真實使用者體驗,涵蓋 Core Web Vitals 指標(如頁面加載速度、互動性、視覺穩定性等)。數據來自訪問量達到門檻的網站,並通過以下方式獲取:

  • BigQuery 數據集:CrUX 資料庫位於 Google Cloud Platform (GCP) 的 BigQuery 上,提供網頁主要來源的使用者體驗效能數據。開發者可以透過 SQL 查詢這些數據以獲取特定洞察,但需要具備 SQL 知識和啟用了帳單的 GCP 專案。這工具特別適合需要自定義報告和基準分析的進階使用者。。
  • API:CrUX API 是一個免費的 RESTful 介面,提供來源或 URL 層級的使用者體驗數據查詢。數據每日更新,並彙總過去 28 天的資料。
  • CrUX Dasboard:以視覺化方式呈現 BigQuery CrUX 資料,用來查看網站的歷史趨勢和效能數據。

https://ithelp.ithome.com.tw/upload/images/20241004/20152073xdnG2GhMWZ.png

使用時機

  • 網站有足夠流量且需要與行業基準比較時。
  • 沒有自行收集 Field 數據或希望補充自行收集的數據。

限制

  • 收集非 Chrome 使用者數據或網站流量不足。
  • 需要即時反映改進(因 CrUX 使用28天的滾動平均數據)。
  • 可公開訪問:網頁必須是公開可用的,不能設置 noindex 標籤或返回 200 以外的 HTTP 狀態碼(如重新導向、404 等)。

(二) Search Console (網站體驗核心指標報表)

Search Console 可以針對特定頁面或將相似頁面分為一個群組進行評估,是基於 CrUX 數據提供洞察,並且僅限網站有權限的使用者使用。

💡TIP
群組為
https://www.example.com/place/001https://www.example.com/place/003 被分在同一群組進行評估
https://ithelp.ithome.com.tw/upload/images/20241004/20152073EPe6oyjMQ5.png

使用時機

  • 開發者和非開發者:適合所有有全縣的角色,評估搜索與頁面效能,提供其他 Google 工具沒有的見解。
  • 獨特的洞察:分組相似頁面並顯示 CrUX 數據,展示效能改進對整個類別的影響。

限制

  • 使用其他分組工具:如果項目使用第三方工具來分組頁面,則 Search Console 可能不適合。
  • 網站未出現在 CrUX 中:如果網站不在 CrUX 數據集中,部分功能無法使用。
  • 分組混淆:若分組中的頁面特點不同,會導致混淆。例如,群組中某些長頁或加載時間較長的頁面可能影響整體評估結果,即使頁面本身表現良好。

(三) Web-Vitals JavaScript 套件

import {onCLS, onINP, onLCP} from 'web-vitals';

onCLS(console.log);
onINP(console.log);
onLCP(console.log);

Web-Vitals.js 是 Google 提供的開源 JavaScript 套件,用於測量網頁的 Core Web Vitals 指標。這個套件簡單且輕量(約 2KB),提供了一種有效的方式來衡量和報告真實使用者的網頁效能體驗。CrUX、PageSpeed Insights 和 Search Console 等工具都基於此套件進行數據收集。

該套件使用了 PerformanceObserverbuffered 標籤,能夠捕捉在套件加載前發生的效能事件,這代表即使延遲加載,也能獲得準確的效能數據。因此,通常建議在其他影響使用者體驗的程式碼加載完成後,再加載 Web-Vitals 以避免影響頁面的初始加載效能。

瀏覽器及功能支援

除了基本用法外,Web-Vitals 還支援將數據傳送至 Google AnalyticsGoogle Tag Manager。瀏覽器支援如下:

  • Chromium 瀏覽器(如 Chrome、Edge、Opera、Samsung Internet):完整支援 Core Web Vitals 指標。
  • Firefox:支援 FCP、LCP、FID 及 TTFB。
  • Safari:僅支援 FCP 及 TTFB。

限制
Web-Vitals 的限制主要來自其依賴的 Web API,特別是在處理 <iframe> 內容時。該套件無法自動測量 iframe 內的效能數據,即便是同源 iframe。如果使用了同源 iframe,開發者需要手動在每個 iframe 中加載 Web-Vitals,並通過 postMessage() 將數據傳遞至主頁面,這增加了開發的複雜性。

Lab

是在受控的實驗環境下測量的網站效能數據,通常使用預定義的網絡和裝置條件進行測試。這樣可以控制變數,確保結果一致且可重複。Lab 資料通常透過 Lighthouse 工具生成,提供可重現的結果。常用的 Lab 測量工具包括:

  • Lighthouse
  • Chrome DevTools
  • WebPageTest

(一) Lighthouse

在瀏覽器中的開發者工具可進行 lighthouse 檢測,在本地和預發布(staging)環境中識別效能改進機會,主要用來發現潛在問題和提供最佳實踐建議,在初始頁面載入期間進行效能評估,但無法分析整個網頁生命週期,例如:帶有記憶體快取的頁面加載、啟用了 Service Worker 的頁面以及潛在的使用者互動。此外,Lighthouse 也提供 Lighthouse CI,用於持續整合和部署階段的效能回歸測試。

⚠️NOTICE
FID 和 INP 為重要的效能指標,但 Lighthouse 無法進行互動分析,所以改以分析 TBT

限制

  1. 無法取代 Field 數據:Lighthouse 只是診斷工具,不應替代 Field 數據,其建議未必與實際使用者體驗一致。
  2. Core Web Vitals 優先:應以 Web Vitals 指標為優先,而非 Lighthouse 的分數,因為 Lighthouse 的效能分數與實際網站體驗不完全相關。

https://ithelp.ithome.com.tw/upload/images/20241004/201520734yo4h0Ztps.png

(二) Chrome DevTools Performance Panel

https://ithelp.ithome.com.tw/upload/images/20241004/201520731IktE9FCVM.png

Chrome DevTools 是瀏覽器內的開發工具,其中的 Performance Panel 是一個實驗室工具,用來剖析頁面加載或記錄的時間段內的所有活動。它能提供有關網路、渲染、繪製、Script 執行及頁面 Core Web Vitals 的深入數據。

使用時機

適合開發者在開發過程中深入分析頁面效能,特別是在解決影響 FID 或 INP 的響應性問題時。當確認到具體的問題後,Performance Panel 可以提供豐富的數據來分析瀏覽器中的問題,例如 main thread 阻塞、JavaScript 調用 call stack 和渲染工作。

限制

僅提供實驗室數據,並不能代替 Field 數據。由於其包含大量 Debug 資訊,對於新手開發者或非開發者來說可能較難理解。

PageSpeed Insights (PSI)

PageSpeed Insights 會提供網頁的 Field 和 Lab 數據。Lab 數據透過 Lighthouse 收集和分析,Field 數據則來自 Chrome 使用者體驗報告 (CrUX) 資料集。當該網址的使用者數量樣本不足時,會使用來源網址的 CrUX 資料作為評估,無法依據特定網頁的數據進行更精細的分析。

🔥TIP
來源網址是指網站的主要域名或根目錄,代表整個網站的統計數據,涵蓋所有頁面的用戶體驗資料。
這個網址則是特定頁面的資料,代表該單一頁面的效能數據,專門針對特定 URL 的用戶體驗進行分析。

而若使用者資料不足時,會無法點擊【這個網址】的實際使用者資料,並顯示 【此網址的實際使用者資料不足。正在改採備用方法,匯總這個來源 (<主要域名或根目錄>) 上所有使用者體驗的資料。】:

https://ithelp.ithome.com.tw/upload/images/20241004/20152073VPvYZPoUCo.png

使用時機

  1. 網頁層級或來源層級評估:PSI 適合評估網頁或整個網站的 Core Web Vitals 指標,適用於行動裝置和桌面使用者。
  2. 初步效能分析:PSI 是了解網頁或網站效能的好起點,提供 Core Web Vitals 及其他效能指標。
  3. 比較網站:可輕鬆比較其他網站的效能表現。
  4. 獲得改善建議:結合 Lighthouse 資料,PSI 提供實用的效能改善建議。

限制

  1. 未公開的網站:PSI 無法分析未公開的開發網站。
  2. 無 CrUX 資料時:若網站不符合 CrUX 資料的資格條件,則無法獲得實際使用者數據,降低 PSI 的效用。
  3. CrUX 和 Lighthouse 資料差異大時:當 CrUX 和 Lighthouse 資料差異顯著時,特別是在 CLSFIDINP 等問題上,Lighthouse 的建議可能較不實用。

Web Vitals Chrome 擴充功能

Web Vitals 擴充功能 是一款適合即時監控的診斷工具,且所有瀏覽器使用者都可以輕鬆使用,非常方便。如果當前網頁的 CrUX 資料列於 CrUX 資料集中,擴充功能會納入這些 CrUX 資料,並提供偵錯資訊,特別針對載入後的問題,例如 CLS 和 INP 指標在互動時可能遇到的問題,協助找出 Core Web Vitals 的效能問題。同時,它也能有效補足 Lighthouse 的不足。

https://web.dev/static/articles/debug-cwvs-with-web-vitals-extension/image/web-vitals-extension-old-c626d13e85df2_856.png?hl=zh-tw

限制

無法提供全方面的效能評估。而且報告中的指標會因執行環境而有顯著差異,開發人員通常使用高效能的設備或快速網路,因此數據可能不完全反映一般使用者的實際體驗。

https://ithelp.ithome.com.tw/upload/images/20241004/20152073hI3zNu8Zm6.png

參考資料

https://www.notion.so/f65331b9801d49dbb5d6edde8aff79b0

https://web.dev/articles/vitals?hl=zh-tw

https://web.dev/articles/defining-core-web-vitals-thresholds?hl=zh-tw

https://web.dev/articles/vitals-measurement-getting-started?hl=zh-tw


上一篇
靠 Grafana 吃飯的第十九天 - 你監控過你的前端嗎? - Real User Monitoring
下一篇
靠 Grafana 吃飯的第二十一天 - Core Web Vitals 指標閾值定義解析
系列文
論前端工程師如何靠 Grafana 吃飯:從 Grafana App 到前端可觀測性30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言