如何使用目前的數據分析工具評估網站使用體驗指標。
能夠評估及回報網頁的實際成效,對於長期診斷及改善成效至關重要。沒有欄位資料,就無法確定你對網站所做的變更是否確實能達成預期的結果。
許多熱門的 實際使用者監控 (RUM) 分析服務供應商,已在其工具中支援 網站使用體驗核心指標 (以及許多其他網站使用體驗指標)。如果您目前使用其中一種 RUM 分析工具,就能評估網站上的網頁是否符合建議的 Core Web Vitals 門檻,並防止日後出現回歸現象。
雖然我們建議使用支援 Core Web Vitals 指標的數據分析工具,但如果您目前使用的數據分析工具不支援這些指標,不一定要切換。幾乎所有數據分析工具都提供方法,可用來定義及評估自訂指標或事件,也就是說,您很可能可以使用目前的數據分析供應商來評估核心網站體驗指標,並將這些指標加入現有的數據分析報表和資訊主頁。
本指南將說明使用第三方或自家分析工具評估 Core Web Vitals 指標 (或任何自訂指標) 的最佳做法。對於希望在服務中加入 Core Web Vitals 支援的數據分析供應商來說,這份指南也相當實用。
使用自訂指標或事件
如上所述,大多數分析工具都允許您評估自訂資料。如果您的數據分析工具支援這項功能,您應該就能使用這個機制評估每項 Core Web Vitals 指標。
在數據分析工具中評估自訂指標或事件通常分為三個步驟:
- 在工具的管理員頁面中定義或註冊自訂指標 (如有需要)。(注意:並非所有數據分析供應商都要求事先定義自訂指標。)
- 在前端 JavaScript 程式碼中計算指標的值。
- 將指標值傳送至 Analytics 後端,確保名稱或 ID 與步驟 1 中定義的內容相符(如有需要,請再次傳送)。
如要瞭解步驟 1 和 3,請參閱分析工具的說明文件。在步驟 2 中,您可以使用 web-vitals JavaScript 程式庫來計算每個 Core Web Vitals 指標的值。
以下程式碼範例說明如何輕鬆在程式碼中追蹤這些指標,並將這些指標傳送至數據分析服務。
import {onCLS, onINP, onLCP} from 'web-vitals';
function sendToAnalytics({name, value, id}) {
const body = JSON.stringify({name, value, id});
// Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
(navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
fetch('/analytics', {body, method: 'POST', keepalive: true});
}
onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);
避免使用平均值
您可能會想計算平均值,以便將一系列成效指標值加總起來。乍看之下,平均值似乎很方便,因為它是大量資料的簡潔摘要,但請不要依賴平均值來解讀網頁成效。
平均值有問題,因為它無法代表任何單一使用者的會話。分布範圍內的離群值可能會誤導平均值。
舉例來說,少數使用者可能會使用速度極慢的網路或裝置,導致值偏高,但由於使用者工作階段數量不足,無法影響平均值,因此無法判斷是否有問題。
請盡可能使用百分位數,而非平均值。針對特定成效指標,分布圖中的百分位數可更準確地描述網站的使用者體驗範圍。這可讓您專注於實際體驗的子集,比單一值更能提供深入分析。
確認您可以檢舉發布內容
計算出各項 Core Web Vitals 指標的值後,請使用自訂指標或事件將這些值傳送至 Analytics 服務,然後建立報表或資訊主頁,顯示已收集到的值。
為確保您符合建議的網站使用體驗核心指標門檻,您需要在報表中顯示各指標的 75 百分位數值。
如果您的數據分析工具未提供內建的百分位數報表,您還是可以透過產生報表,手動取得每個指標值並以遞增順序排序。產生這份報表後,報表中所有值的完整排序清單中,75% 的結果就是該指標的 75 百分位數,無論您如何區隔資料 (依裝置類型、連線類型、國家/地區等) 都一樣。
如果您的數據分析工具預設不會提供指標層級報表細目,只要數據分析工具支援自訂維度,您應該就能取得相同的結果。只要為您追蹤的每個指標個別例項設定專屬的自訂維度值,即可產生報表,並依個別指標個別例項進行細分 (前提是您在報表設定中加入自訂維度)。由於每個例項都有專屬的維度值,因此系統不會進行分組。
網站重要指標報表就是使用 Google Analytics 的這項技術的範例。這份報告的程式碼為開放原始碼,開發人員可以參考這份報告,瞭解本節所述的技術。
在適當時間傳送資料
有些效能指標可在網頁載入完成後計算,其他指標 (例如 CLS) 則會考量網頁的整個生命週期,並在網頁開始卸載後才算出最終結果。
不過,由於 beforeunload
和 unload
事件都不可靠 (尤其是在行動裝置上),因此不建議使用這類事件 (因為這可能會導致網頁無法使用往返快取)。
對於追蹤網頁整個生命週期的指標,建議您在 visibilitychange
事件中傳送指標的目前值,並在網頁的顯示狀態變更為 hidden
時傳送。這是因為一旦頁面的顯示狀態變更為 hidden
,就無法保證該頁面上的任何指令碼能夠再次執行。這點在行動作業系統上尤其重要,因為瀏覽器應用程式本身可以關閉,而不會觸發任何頁面回呼。
請注意,行動作業系統通常會在切換分頁、切換應用程式或關閉瀏覽器應用程式時觸發 visibilitychange
事件。關閉分頁或前往新頁面時,也會觸發 visibilitychange
事件。這使得 visibilitychange
事件比 unload
或 beforeunload
事件可靠得多。
長期監控成效
更新數據分析導入作業,以便追蹤及回報網站體驗核心指標,接下來請追蹤網站變更對長期效能造成的影響。
管理變更版本
追蹤變更的簡單 (但最終不可靠) 方法,就是將變更部署至實際環境,然後假設部署日期後收到的所有指標都與新網站相符,而部署日期前收到的所有指標都與舊網站相符。不過,許多因素 (包括在 HTTP、服務工作者或 CDN 層級快取) 都可能導致這項功能無法運作。
更理想的做法是針對每個已部署的變更建立專屬版本,然後在數據分析工具中追蹤該版本。大多數的數據分析工具都支援設定版本。如果沒有,您可以建立自訂維度,並將該維度設為已部署的版本。
執行實驗
您可以同時追蹤多個版本 (或實驗),進一步使用版本管理功能。
如果您可以使用數據分析工具定義實驗組,請使用這項功能。否則,您可以使用自訂維度,確保每個指標值都能與報表中的特定實驗群組相關聯。
在 Analytics 中設定實驗後,您就可以向部分使用者推出實驗變更,並比較該變更的成效與控制組使用者成效。一旦確信變更確實可改善成效,即可向所有使用者推出。
確保評估不會影響效能
在評估真實使用者的成效時,您執行的任何成效評估程式碼絕對不得對網頁成效造成負面影響。如果是這樣,您就無法得知成效對業務的影響,因此無法做出任何結論,因為您永遠無法確定是否是分析程式碼本身造成最大的負面影響。
在實際網站上部署 RUM 分析程式碼時,請務必遵循下列原則:
延後數據分析
Analytics 代碼一律應以非同步、非阻斷的方式載入,且通常應在最後載入。如果您以阻斷方式載入數據分析程式碼,可能會對 LCP 造成負面影響。
用於評估 Core Web Vitals 指標的所有 API 均專門設計用於支援非同步和延遲的指令碼載入作業 (透過 buffered
標記),因此您不必急著提早載入指令碼。
如果您要評估的評估指標無法在網頁載入時間表的後續階段計算,請僅將需要提早執行的程式碼內嵌至文件的 <head>
中 (因此不會造成轉譯阻斷請求),並延後執行其餘程式碼。請勿因為單一指標需要,就提早載入所有 Analytics。
請勿建立長時間的工作
Analytics 程式碼通常會在回應使用者輸入時執行,但如果 Analytics 程式碼執行大量 DOM 測量或使用其他耗用大量處理器的 API,Analytics 程式碼本身可能會導致輸入回應速度變慢。此外,如果包含分析程式碼的 JavaScript 檔案很大,執行該檔案可能會阻斷主執行緒,並對網頁的Interaction to Next Paint (INP) 造成負面影響。
使用非封鎖式 API
sendBeacon()
和 requestIdleCallback()
等 API 是專門用於執行非重要工作,且不會阻斷使用者重要工作的 API。
這些 API 是 RUM 分析程式庫中非常實用的工具。
一般來說,所有數據分析信標都應使用 sendBeacon()
API (如有) 傳送,所有被動數據分析評估程式碼也應在閒置期間執行。
請勿追蹤不必要的資料
瀏覽器會提供大量效能資料,但即使資料可供使用,也不一定代表您應該記錄並傳送至數據分析伺服器。
舉例來說,Resource Timing API 會針對網頁載入的每個資源提供詳細的時間資料。不過,並非所有資料都會對改善資源載入效能有所幫助。
簡而言之,請勿只因資料存在而追蹤資料,請確保在耗用追蹤資料的資源前,先使用該資料。