如何使用目前的數據分析工具評估網站體驗指標。
能夠評估並記錄廣告活動的實際成效 網頁對長期診斷及改善成效而言至關重要。不含 欄位 資料 因此無法確定你對網站所做的變更是否生效 確實達到預期成果
許多熱門的真人使用者監控 (RUM) 分析服務供應商 已支援 Core Web Vitals 指標 工具 (以及其他 Web Vitals 中的許多功能)如果您是 正在使用其中一種 RUM 分析工具 評估你網站上的網頁是否符合建議的網站體驗核心指標 臨界值,避免發生迴歸問題
雖然建議使用支援 Core Web Vitals 的分析工具 若您目前使用的分析工具不支援這些指標 就算沒有改用幾乎所有數據分析工具 定義及測量 指標或 事件,意味著 能使用您目前的分析服務供應商來評估 Core Web Vitals 指標,然後加進您現有的 Analytics 報表和資訊主頁。
本指南將探討使用第三方或內部分析工具評估 Core Web Vitals 指標 (或任何自訂指標) 的最佳做法。如果分析供應商希望對自家服務新增 Core Web Vitals 支援,這份指南也能做為指引。
使用自訂指標或事件
如前所述,大部分的數據分析工具都可用來評估自訂資料。如果您的 分析工具支援這項做法,因此,您應該 使用這項機制的 Vitals 指標
在數據分析工具中評估自訂指標或事件 三個步驟:
- 定義或 註冊 編輯工具中的自訂指標 (如有需要)。(注意:並非全部 分析服務供應商需要事先定義自訂指標)。
- 在前端 JavaScript 程式碼中計算指標值。
- 將指標值傳送至數據分析後端,確認名稱或 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
事件。
持續監控成效變化
更新 Analytics 導入設定, 網站體驗核心指標指標的下一步是追蹤網站更新 長期下來對成效的影響
版本變更
追蹤變更的一個單純 (且最終不可靠) 的方法就是 變更實際工作環境的所有指標,並假設在 部署日期對應新網站和 部署日期會對應至舊的協作平台。不過所有因素 (包括在 HTTP、Service Worker 或 CDN 層執行快取) 可避免這項作業 工作。
更好的做法是為每個部署的變更建立專屬版本 使用數據分析工具追蹤該版本大部分數據分析工具都支援 以及設定版本如果沒有,您可以建立自訂維度 新增至部署版本
執行實驗
您還可以追蹤多個版本 (或
如果數據分析工具允許您定義實驗群組,請使用該功能; 反之,您可以運用自訂維度確保每個指標值 可與報表中的某個實驗群組建立關聯。
在數據分析進行實驗後 對部分使用者進行實驗,然後比較 控制組使用者的效能變化 相信改變確實能提升成效,並 所有使用者。
確保評估結果不會影響成效
評估實際使用者的成效時,務必確保任何 您運作的成效評估程式碼不會對 以及您網頁成效的部分如果答案為是,那麼您嘗試得出任何結論 因此,您一定不需要 永遠不知道數據分析程式碼是否在 可能會產生負面影響
在自己的機器上部署 RUM 分析程式碼時,請務必遵循這些原則 製作網站:
延後數據分析
Analytics 程式碼應一律以 非同步、非封鎖的方式載入,且 通常應該最後載入如果您在 以免對 LCP 造成負面影響
具體來說,用來評估 Core Web Vitals 指標的所有 API
專為非同步和延遲載入指令碼而設計 (透過
buffered
標記),因此
您不需要急著立即載入指令碼。
如果評估的指標之後無法計算,
網頁載入時間軸,建議您「只」內嵌需要提早執行的程式碼
加到文件的 <head>
中 (因此不是禁止轉譯)
) 並延遲其餘部分。建議您不要載入所有
數據分析只會因為一項指標才有需求
不要建立長時間的工作
Analytics 程式碼經常會在回應使用者輸入時執行,但如果您的 Analytics 程式碼 進行大量的 DOM 測量,或使用其他處理器的 API Analytics 程式碼本身可能會導致輸入回應速度過慢。此外,如果 包含分析程式碼的 JavaScript 檔案很大,正在執行該檔案 可能會封鎖主執行緒,並對網頁的與下一個顯示的內容互動 (INP) 造成負面影響。
使用非阻塞 API
API,例如
sendBeacon()
和
requestIdleCallback()
專為執行非重要工作而設計
並且封鎖使用者重要工作
這些 API 非常適合用於 RUM 數據分析資料庫的工具。
一般而言,所有數據分析信標都應使用 sendBeacon()
API 傳送
(如果有的話),所有被動分析評估程式碼都應在
閒置期間。
不要追蹤過多資訊
瀏覽器公開大量成效資料 不代表一定要錄下節目,並傳給 數據分析伺服器
例如 Resource Timing API 可為網頁上載入的每個資源提供詳細的時間資料。 然而,這些資料不一定都完全或 提高資源負載效能
簡而言之,不要只追蹤資料,因為請確保資料能使用 再使用資源追蹤