瞭解如何使用偵錯資訊來歸因成效資料 運用數據分析,找出並修正使用者實際問題
Google 提供兩種成效評估及偵錯工具:
- 研究室工具:Lighthouse 等工具,工具會在 能模擬各種狀況的模擬環境,例如 以及低階行動裝置)。
- 現場工具:工具,例如 Chrome 使用者體驗 檢舉 (CrUX) 的資料,是根據 Chrome 的匯總實際使用者資料計算而來。(請注意, 由 PageSpeed 等工具回報的欄位資料 洞察資料和搜尋 控制台的來源 CrUX 資料)。
現場工具則可提供更準確的資料,而這些資料能確實反映 實際使用者體驗,研究室工具通常更能協助您找出並修正 以負載平衡機制分配流量 即可降低應用程式發生效能問題的風險
CrUX 資料更能代表網頁的實際成效 CrUX 分數無法協助您找出改善方法 才需進行
另一方面,Lighthouse 會找出問題並明確列出 提供改善建議不過,Lighthouse 只會提供建議 。未偵測出問題 只因使用者互動 (例如捲動或點擊) 而顯示 按鈕。
這會產生一個重要問題:如何擷取 Google 服務的偵錯資訊 Core Web Vitals 還是實際使用者提供的其他成效指標?
本文將詳細說明可以使用哪些 API 來收集其他 針對每個目前的 Core Web Vitals 指標偵錯資訊 思考如何在現有的分析工具中擷取這些資料。
用於歸因和偵錯的 API
累計版面配置位移 (CLS)
在所有 Core Web Vitals 指標中,CLS 可能是 在欄位中收集偵錯資訊是最重要的會測量 CLS 在整個網頁瀏覽效期內 網頁 - 捲動多少位置、點擊的內容等 看看版面配置位移以及哪些元素會位移。
請參考 PageSpeed Insights 提供的下列報告:
![含有不同 CLS 值的 PageSpeed Insights 報表](https://web.dev/static/articles/debug-performance-in-the-field/image/psi-cls-difference.png?authuser=1&hl=zh-tw)
相較於 CLS,研究室所回報的 CLS 價值是來自於 會發現許多不同領域 (CrUX 資料) 都相當合理 網頁中可能含有許多互動內容 在 Lighthouse 中進行測試時不會使用。
但即使您瞭解使用者互動會影響欄位資料, 哪些元素會變動,導致 0.28 分 第 75 個百分位數「LayoutShiftAttribution」LayoutShiftAttribution 介面就能達成目的
取得版面配置位移歸因
「LayoutShiftAttribution」LayoutShiftAttribution
在版面配置不穩定的每個 layout-shift
項目上,都會顯示介面
API 發出。
如需這兩種介面的詳細說明,請參閱偵錯版面配置 位移。用途 這篇文章的主要重點在於,開發人員可以 觀察網頁上發生的所有版面配置位移,以及哪些元素 科技可說是瞬息萬變
以下程式碼範例會記錄每個版面配置位移以及元素 轉變:
new PerformanceObserver((list) => {
for (const {value, startTime, sources} of list.getEntries()) {
// Log the shift amount and other entry info.
console.log('Layout shift:', {value, startTime});
if (sources) {
for (const {node, curRect, prevRect} of sources) {
// Log the elements that shifted.
console.log(' Shift source:', node, {curRect, prevRect});
}
}
}
}).observe({type: 'layout-shift', buffered: true});
為 Google Analytics 資料製作及傳送資料到數據分析工具可能不是實際的 發生的每個版面配置位移;然而,藉由監控所有變動 藉此追蹤最差的變動,只回報這些變化的相關資訊。
目標不是識別及修正所有發生中的 目的是找出影響最大的 因此在第 75 個百分位數,對您網頁的 CLS 貢獻最大。
此外,您不需要在每次有新內容時 計算最大的來源元素 只有在您準備將 CLS 值傳送至 數據分析工具
以下程式碼列出了已貢獻的 layout-shift
個項目
並傳回最大的來源元素:
function getCLSDebugTarget(entries) {
const largestEntry = entries.reduce((a, b) => {
return a && a.value > b.value ? a : b;
});
if (largestEntry && largestEntry.sources && largestEntry.sources.length) {
const largestSource = largestEntry.sources.reduce((a, b) => {
return a.node && a.previousRect.width * a.previousRect.height >
b.previousRect.width * b.previousRect.height ? a : b;
});
if (largestSource) {
return largestSource.node;
}
}
}
找出影響力最大的元素後 可以向數據分析工具回報
在某個網頁上,對 CLS 影響最大的元素可能不同 但如果您將這幾類元素彙整在一起 產生一份清單,列出影響最多使用者人數的位移元素。
找出並修正廣告變化的根本原因後 資料,Analytics 程式碼就會開始記錄較小的位移,因為「最差」 新的內容。最後,所有回報的變動幅度都夠小 您的網頁成效良好門檻 0.1!
有助於連同最大變動幅度的其他中繼資料 來源元素為:
- 出現最大變動的時間
- 最大的轉變發生時的網址路徑 (適用於採用動態調整技術的網站 更新網址,例如單一頁面應用程式)。
最大內容繪製 (LCP)
如要對欄位中 LCP 偵錯,您需要主要的資訊 元素是該特定問題的最大元素 (LCP 候選元素) 載入網頁。
請注意,LCP 是完全可行的,實際上,這種狀況是很常見的情況 候選元素會因使用者而異,即使是完全相同的字詞 頁面。
問題的原因如下:
- 使用者裝置的螢幕解析度不同,這會導致 網頁版面配置,因此可視區域中顯示的不同元素。
- 使用者不一定會載入捲動至最頂端的網頁。連結通常都會 包含片段 ID,甚至 「文字片段」,也就是說, 才能載入網頁並顯示在頁面上任何捲動位置
- 內容可針對目前的使用者提供個人化內容,因此 LCP 候選元素 可能會有差異
換言之,您無法假設哪些元素或一組元素 是特定網頁最常見的 LCP 候選元素。您必須 也能依據使用者實際行為進行評估
找出 LCP 候選元素
如要判斷 JavaScript 中的 LCP 候選元素,您可以使用 Largest Contentful Paint API 也就是用來決定 LCP 時間值的 API
觀察 largest-contentful-paint
項目時,您可以判斷
透過查看最後一個項目的 element
屬性,找出目前 LCP 候選元素:
new PerformanceObserver((list) => {
const entries = list.getEntries();
const lastEntry = entries[entries.length - 1];
console.log('LCP element:', lastEntry.element);
}).observe({type: 'largest-contentful-paint', buffered: true});
瞭解 LCP 候選元素後,就能將其傳送至數據分析工具 以及指標值如同 CLS,這有助於找出 最佳化的重要性
除了 LCP 候選元素之外,評估 LCP LCP 子部分的時間,非常實用 ,判斷與網站相關的具體最佳化步驟。
與下一個顯示的內容互動 (INP)
在 INP 欄位中需要擷取的最重要資訊如下:
- 使用者與哪個元素互動
- 為什麼會有互動類型?
- 發生該互動的時間
互動速度緩慢的主因是主執行緒遭到封鎖 常見情況瞭解互動速度是否最慢 能協助判斷需要採取的修正方式 問題。
INP 指標會將 互動,包括執行 以及所有事件接聽程式後繪製下一個影格所需的時間 執行。這意味著對於 INP 來說 元素往往會導致互動速度緩慢, 例如:
下列程式碼會記錄 INP 項目的目標元素和時間。
function logINPDebugInfo(inpEntry) {
console.log('INP target element:', inpEntry.target);
console.log('INP interaction type:', inpEntry.name);
console.log('INP time:', inpEntry.startTime);
}
請注意,這個程式碼並未說明如何判斷哪個 event
項目是 INP
因為這個邏輯比較牽涉到不過,下節將說明
如何透過
web-vitals JavaScript 程式庫。
搭配 Web-Vitals JavaScript 程式庫使用
前幾節會提供一些一般建議和程式碼範例,說明要擷取的內容 請在傳送給數據分析工具的資料中加入偵錯資訊。
自第 3 版以來,web-vitals JavaScript 程式庫提供歸因 建構 其中會顯示所有這些資訊,另外還有幾個 信號
以下程式碼範例說明如何設定其他事件 參數 (或 custom 維度)),其中包含 偵錯字串有助於找出效能的根本原因 以負載平衡機制分配流量 即可降低應用程式發生效能問題的風險
import {onCLS, onINP, onLCP} from 'web-vitals/attribution';
function sendToGoogleAnalytics({name, value, id, attribution}) {
const eventParams = {
metric_value: value,
metric_id: id,
}
switch (name) {
case 'CLS':
eventParams.debug_target = attribution.largestShiftTarget;
break;
case 'LCP':
eventParams.debug_target = attribution.element;
break;
case 'INP':
eventParams.debug_target = attribution.interactionTarget;
break;
}
// Assumes the global `gtag()` function exists, see:
// https://developers.google.com/analytics/devguides/collection/ga4
gtag('event', name, eventParams);
}
onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);
此程式碼僅供 Google Analytics 使用,但基本原則是 和其他數據分析工具一樣
此程式碼也顯示如何回報單一偵錯信號 多方收集並記錄多種不同信號 指標。
舉例來說,如要對 INP 偵錯,建議您收集 互動類型、互動類型、時間、loadState、 階段等 (例如長動畫影格資料)。
web-vitals
歸因版本會顯示額外的歸因資訊
如以下範例 INP 所示:
import {onCLS, onINP, onLCP} from 'web-vitals/attribution';
function sendToGoogleAnalytics({name, value, id, attribution}) {
const eventParams = {
metric_value: value,
metric_id: id,
}
switch (name) {
case 'INP':
eventParams.debug_target = attribution.interactionTarget;
eventParams.debug_type = attribution.interactionType;
eventParams.debug_time = attribution.interactionTime;
eventParams.debug_load_state = attribution.loadState;
eventParams.debug_interaction_delay = Math.round(attribution.inputDelay);
eventParams.debug_processing_duration = Math.round(attribution.processingDuration);
eventParams.debug_presentation_delay = Math.round(attribution.presentationDelay);
break;
// Additional metric logic...
}
// Assumes the global `gtag()` function exists, see:
// https://developers.google.com/analytics/devguides/collection/ga4
gtag('event', name, eventParams);
}
onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);
請參閱網路 Vitals 歸因 說明文件 已曝光偵錯信號的完整清單。
製作資料報表並以視覺化方式呈現
開始收集偵錯資訊和指標值後 下一步就是匯總所有使用者的資料 例如模式、趨勢和趨勢
如前所述,您不必解決所有問題 則您需要先解決使用者遇到的情況,尤其是 影響最多的使用者,這應該也會造成 對 Core Web Vitals 分數的影響最大。
如果是 GA4,請參閱這篇專屬文章,瞭解如何使用 BigQuery:
摘要
希望這篇文章已概述如何運用
現有的效能 API 和 web-vitals
程式庫可取得偵錯資訊
,根據實際使用者在當地的實際造訪情形診斷成效。雖然這是
本指南著重於「Core Web Vitals」報告,但相關概念也適用於偵錯
所有可透過 JavaScript 評估的成效指標
如果您才剛開始評估成效 Google Analytics 使用者,不妨先從「網站體驗指標報告」工具著手 因為這項功能已經支援網站 對 Core Web 的偵錯資訊 Vitals 指標
如果您是分析服務供應商,且想改善自家產品 提供了更多偵錯資訊給使用者,請考慮採用 此處介紹的技巧,但不侷限於這裡提供的想法 此處。這篇文章適用於所有數據分析工具。 不過,各個分析工具可能 (也應該) 擷取並記錄 以及更多偵錯資訊
最後,如果您認為在偵錯這些指標上 API 本身缺少功能或資訊 web-vitals-feedback@googlegroups.com.