本頁面由 Cloud Translation API 翻譯而成。

偵錯欄位效能

瞭解如何使用偵錯資訊來歸因成效資料運用數據分析，找出並修正使用者實際問題

Philip Walton

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 報表 — PageSpeed Insights 會顯示欄位和研究室資料 (如果有的話，這些資料可能不同)

相較於 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.