提供意見回饋:一項實驗性回應指標

評估網路回應速度的最新計畫。

Hongbo Song
Hongbo Song

今年稍早,Chrome 速度指標團隊分享了 構思提案內容 新的反應指標我們想設計一個能更精準地 個別事件的端對端延遲時間,可讓您更全面地掌握 網頁在生命週期的整體回應速度。

過去幾個月來,我們已大幅提升這項指標的進展 想與您分享一份最新消息,說明我們打算如何評估互動延遲 因為導入了幾項我們考慮量化的匯總選項 網頁的整體回應。

我們也希望能收到開發人員和網站擁有者的意見回饋,包括: 其中哪一個選項最能代表 網頁回應。

評估互動延遲時間

做為審查結果,「First Input Delay (FID)」指標會擷取 延遲部分。也就是說 當使用者與網頁互動,到事件處理常式 這個 API 可以順利運作

推出這項新指標後,我們預計將更多指標提供給更多使用者,藉此掌握完整事件資訊 持續時間,從 ,直到所有事件處理常式完成繪製下一個影格為止 執行。

我們也打算 而不是個別事件互動是指符合以下條件的一組事件: 會做為相同邏輯使用者手勢的一部分來調派 (例如: pointerdownclickpointerup) 時發生當機。

評估一組個別事件的總互動延遲時間 期間,我們考慮採用兩種可能的做法:

  • 事件持續時間上限:互動延遲時間等於最大 這是指互動群組內任何事件的單一事件持續時間。
  • 總事件持續時間:互動延遲時間是所有事件的總和 持續時間,忽略重疊部分。

例如,下圖顯示按鍵互動,其中包含 在 keydownkeyup 事件觸發事件。在本例中,時間長度重疊 。如要測量按鍵互動的延遲時間, 我們可以使用 max(keydown duration, keyup duration)sum(keydown duration, keyup duration) - duration overlap

A 罩杯
根據事件持續時間顯示互動延遲時間的圖表

每種方法各有優缺點,因此我們希望能收集更多資料, feedback

,瞭解如何調查及移除這項存取權。

匯總每頁的所有互動

一旦我們能夠測量所有互動的端對端延遲時間, 定義單次造訪的匯總分數 跨多個互動

我們探索了多種選項後,我們縮小了 下一節概述的策略 並收集實際使用者資料我們計劃將 我們累積了足夠的資料後,還需要收集更多資料 ,直接向網站擁有者提供意見回饋,瞭解該策略適合哪些策略 最能準確反映網頁的互動模式。

匯總策略選項

為了說明下列各項策略,請考慮使用網頁造訪範例 其中包含四個互動:

互動 延遲時間
(按一下滑鼠) 120 毫秒
(按一下滑鼠) 20 毫秒
按鍵效果 60 毫秒
按鍵效果 80 毫秒

最差的互動延遲時間

頁面上發生的最大個別互動延遲時間。由於 上述互動的例子,最糟的互動延遲時間為 120 毫秒。

預算策略

使用者體驗 研究 表示使用者可能不會察覺到延遲時間低於特定門檻 負面。我們根據這項研究,考慮採用幾種預算策略 為每個事件類型使用下列門檻值:

互動類型 預算門檻
按一下/輕觸 100 毫秒
拖曳 100 毫秒
鍵盤 50 毫秒

每項策略都只會將延遲時間大於 單次互動的預算門檻以上述範例網頁造訪為例, 超出預算的金額如下:

互動 延遲時間 超出預算的延遲時間
按一下 120 毫秒 20 毫秒
按一下 20 毫秒 0 毫秒
按鍵操作 60 毫秒 10 毫秒
按鍵操作 80 毫秒 30 毫秒

超出預算時最差的互動延遲時間

超出預算的最大單一互動延遲時間。就以上範例來說 分數會是 max(20, 0, 10, 30) = 30 ms

超出預算的總互動延遲時間

超出預算的所有互動延遲時間總和。就以上範例來說 分數會是 (20 + 0 + 10 + 30) = 60 ms

超出預算的平均互動延遲時間

超預算互動總延遲除以 互動情形以上述範例來說,分數會是 (20 + 0 + 10 + 30) / 4 = 15 ms

高分位數近似值

除了計算預算之外,計算最大的互動延遲時間之外, 也考慮使用高分位數近似值 與高互動性高的網頁 離群值不相上下我們發現兩個可能的高分位數近似策略 我們喜歡:

  • 選項 1:追蹤最大和第二大的互動, 預算。每發生 50 次新互動後,就從 並加入目前一組 50 中,然後將目前 50 組中最大的互動。 最終價值是比預算的最大剩餘互動。
  • 選項 2:針對預算計算最大的 10 次互動,然後選擇 根據互動總數選擇該指標的值。指定 N 選取 (N / 50 + 1) 最大的值或第 10 個值 適合互動超過 500 次的網頁

在 JavaScript 中評估這些選項

以下程式碼範例可用來判斷 提供的三個策略請注意,目前尚無法評估 網頁使用 JavaScript 時的互動總數,因此這個範例不會 包括「平均互動比預算策略」或「高 分位數估算策略

const interactionMap = new Map();

let worstLatency = 0;
let worstLatencyOverBudget = 0;
let totalLatencyOverBudget = 0;

new PerformanceObserver((entries) => {
  for (const entry of entries.getEntries()) {
    // Ignore entries without an interaction ID.
    if (entry.interactionId > 0) {
      // Get the interaction for this entry, or create one if it doesn't exist.
      let interaction = interactionMap.get(entry.interactionId);
      if (!interaction) {
        interaction = {latency: 0, entries: []};
        interactionMap.set(entry.interactionId, interaction);
      }
      interaction.entries.push(entry);

      const latency = Math.max(entry.duration, interaction.latency);
      worstLatency = Math.max(worstLatency, latency);

      const budget = entry.name.includes('key') ? 50 : 100;
      const latencyOverBudget = Math.max(latency - budget, 0);
      worstLatencyOverBudget = Math.max(
        latencyOverBudget,
        worstLatencyOverBudget,
      );

      if (latencyOverBudget) {
        const oldLatencyOverBudget = Math.max(interaction.latency - budget, 0);
        totalLatencyOverBudget += latencyOverBudget - oldLatencyOverBudget;
      }

      // Set the latency on the interaction so future events can reference.
      interaction.latency = latency;

      // Log the updated metric values.
      console.log({
        worstLatency,
        worstLatencyOverBudget,
        totalLatencyOverBudget,
      });
    }
  }
  // Set the `durationThreshold` to 50 to capture keyboard interactions
  // that are over-budget (the default `durationThreshold` is 100).
}).observe({type: 'event', buffered: true, durationThreshold: 50});
敬上

意見回饋

我們鼓勵開發人員試用這些新回應速度指標, 網站,如果發現任何問題,請通知我們。

請將有關本文所述做法的一般意見回饋,透過電子郵件傳送至 web-vitals-feedback Google 群組顯示「[回應指標]」做為主旨我們想要 期待您的回覆!