First Input Delay (FID)

Philip Walton

我們都知道，給人留下良好的第一印象非常重要。這在認識新朋友時很重要，在建立網路體驗時也同樣重要。

在網路上，良好的第一印象可以讓使用者成為忠實使用者，或是離開並永不回頭。問題是，要獲得良好曝光的意義為何？如何評估使用者可能看到的廣告曝光類型？

在網路上，初次曝光可能會有許多不同的形式，例如網站設計和視覺吸引力的首度，以及網站速度和回應速度的首次曝光。

雖然很難評估使用者對網站設計的喜愛程度，但評估網站速度和回應速度則是可行的！

使用者對網站載入速度的第一印象，可以透過首次顯示內容所需時間 (FCP) 來評估。不過，網站將像素繪製到螢幕的速度只是其中一部分。此外，當使用者嘗試與這些像素互動時，網站的回應速度也同樣重要！

首次輸入延遲時間 (FID) 指標可協助評估使用者對網站互動性和回應速度的第一印象。

什麼是 FID？

FID 會評估從使用者首次與網頁互動 (例如點選連結、輕觸按鈕或使用自訂的 JavaScript 驅動控制項) 起算，到瀏覽器實際能夠開始處理事件處理常式，以回應該互動所需的時間。

FID 分數良好的是什麼？

為了提供良好的使用者體驗，網站應力求將首次輸入延遲時間設為 100 毫秒以下。為確保多數使用者都能享有此等級的體驗，建議您以頁面載入的第 75 個百分位數做為門檻，並區分行動裝置和電腦。

FID 詳細資訊

開發人員會編寫回應事件的程式碼，因此我們經常假設程式碼會在事件發生後立即執行。但身為使用者，我們經常會遇到相反的情況，也就是在手機上載入網頁，並嘗試與之互動，但卻什麼事都沒發生，讓人感到沮喪。

一般來說，當瀏覽器的主執行緒正忙於執行其他作業，因此輸入延遲 (即輸入延遲時間) 就會發生，因此使用者目前無法回應。發生這種情況的常見原因是瀏覽器正忙於剖析及執行應用程式載入的大型 JavaScript 檔案。在執行這項作業時，瀏覽器無法執行任何事件監聽器，因為載入的 JavaScript 可能會指示瀏覽器執行其他動作。

請參考下列典型網頁載入作業的時間軸：

在上方的視覺化圖表中，有一個頁面會向資源 (最有可能是 CSS 和 JS 檔案) 發出一些網路要求，並在這些資源下載完成後，於主執行緒上處理。

這會導致主執行緒暫時忙碌的時間，以米色工作區塊表示。

首次輸入延遲時間通常在首次內容繪製 (FCP) 和互動時間 (TTI) 之間發生，因為頁面已轉譯部分內容，但互動不穩定。為了說明這種情況的發生方式，我們已在時間軸中加入 FCP 和 TTI：

您可能會發現，FCP 和 TTI 之間有相當長的時間差距 (包括三個長時間工作)，如果使用者在該期間嘗試與網頁互動 (例如點選連結)，在收到點擊事件與主執行緒能夠回應之間，會有一段延遲時間。

試想如果長時間工作開始進行時，使用者嘗試與網頁互動，會發生什麼情況：

由於輸入內容是在瀏覽器執行工作期間進行，因此必須等到工作完成之後，才能回應輸入內容。必須等待的時間是這個使用者在這個網頁上的 FID 值。

如果互動沒有事件監聽器，該怎麼辦？

FID 會評估從收到輸入事件到主執行緒下次閒置之間的差異。也就是說，即使未註冊事件監聽器，系統也會評估 FID。原因是許多使用者互動不需要事件監聽器，但確實需要主要執行緒處於閒置狀態才能執行。

舉例來說，下列所有 HTML 元素都需要等待主執行緒上進行中的工作完成，才能回應使用者互動：

• 文字欄位、核取方塊和圓形按鈕 (<input>、<textarea>)
• 選取下拉式選單 (<select>)
• 連結 (<a>)

為什麼只考慮第一個輸入內容？

雖然任何輸入延遲都可能導致使用者體驗不佳，但我們主要建議您評估第一個輸入延遲時間，原因如下：

• 首次輸入延遲時間會是使用者對網站回應的第一印象，而第一印像是影響網站品質和可靠性整體曝光的重要關鍵。
• 目前網站上最嚴重的互動問題，發生在網頁載入期間。因此，我們認為，一開始著重改善網站的首次使用者互動，將對改善網路的整體互動性產生最大影響。
• 針對網站應如何修正高初始輸入延遲時間的建議解決方案 (分割程式碼、預先載入較少的 JavaScript 等)，不一定適用於修正網頁載入後輸入延遲時間緩慢的問題。藉由區隔這些指標，我們就能為網頁程式開發人員提供更具體的效能指南。

哪些項目會視為第一次輸入？

FID 是用於評估網頁在載入期間的回應速度。因此，它只會著重在獨立的動作 (例如點擊、輕觸和按鍵操作) 的輸入事件。

捲動和縮放等其他互動屬於連續的動作，且具有完全不同的效能限制 (瀏覽器通常可以在另一個執行緒上執行程式碼，以隱藏延遲時間)。

為此，FID 著重於 RAIL 效能模型中的 R (反應性)，而捲動和縮放與 A (動畫) 更相關，且應分別評估其效能特質。

如果使用者從未與您的網站互動，該怎麼辦？

不是所有使用者每次造訪您的網站時，都會與網站互動。而且，並非所有互動都與 FID 相關 (如上一節所述)。此外，部分使用者初次互動會有不理想的時間 (主執行緒忙碌時間較長時)，且部分使用者第一次互動的時段會是適當 (主執行緒完全閒置時)。

這表示部分使用者不會有 FID 值、有些使用者的 FID 值偏低，有些使用者的 FID 值可能較高。

追蹤、回報和分析 FID 的方式，可能與您慣用的其他指標有相當大的差異。下一節將說明如何最佳化這項作業。

為什麼只考量輸入延遲時間？

如上所述，FID 只會測量事件處理中的「延遲」。不會測量事件處理期間本身的總時間，也不會測量執行事件處理常式後瀏覽器更新 UI 所需的時間。

雖然這段時間對使用者來說很重要，且確實會影響使用體驗，但這項指標並未納入其中，因為這麼做可能會促使開發人員新增實際上會使使用體驗變差的解決方法，也就是說，他們可能會在非同步回呼 (透過 setTimeout() 或 requestAnimationFrame()) 中包裝事件處理常式邏輯，以便將其與與事件相關聯的工作區隔開來。結果是指標分數會改善，但使用者會感覺回應速度變慢。

不過，雖然 FID 只會測量事件延遲時間的「延遲」部分，但開發人員如果想要追蹤更多事件生命週期，可以使用 Event Timing API 執行此操作。詳情請參閱自訂指標相關指南。

如何評估 FID

FID 是只能在實驗室中測量的指標，因為這項指標需要真實使用者與網頁互動。您可以使用下列工具評估 FID。

現場工具

• Chrome 使用者體驗報告
• PageSpeed Insights
• Search Console (Core Web Vitals 報表)
• web-vitals JavaScript 程式庫

在 JavaScript 中評估 FID

如要在 JavaScript 中評估 FID，您可以使用 Event Timing API。以下範例說明如何建立 PerformanceObserver 來監聽 first-input 項目，並將其記錄到控制台：

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const delay = entry.processingStart - entry.startTime;
    console.log('FID candidate:', delay, entry);
  }
}).observe({type: 'first-input', buffered: true});

在上述範例中，系統會計算項目 startTime 和 processingStart 時間戳記之間的差距，藉此測量 first-input 項目的延遲時間值。在大多數情況下，這會是 FID 值；不過，並非所有 first-input 項目都適用於評估 FID。

下節將列出 API 回報內容和計算指標的方式之間的差異。

指標和 API 的差異

• API 會為背景分頁中載入的頁面分派 first-input 項目，但計算 FID 時，請忽略這些網頁。
• 如果頁面是在第一個輸入發生之前於背景執行，API 也會分派 first-input 項目，但計算 FID 時，也應該忽略這些網頁 (只有在頁面在前景中處於前景時才會考量輸入)。
• 當網頁從回溯/前進快取還原時，API 不會回報 first-input 項目，但在這種情況下，應評估 FID，因為使用者會將其視為不同的網頁瀏覽。
• API 不會回報在 iframe 內發生的輸入內容，但指標是因網頁使用者體驗的一部分而產生的。這可能顯示為 CrUX 和 RUM 之間的差異。為了正確評估 FID，您應該將 FID 納入考量。子頁框可以使用 API 向父項頁框回報 first-input 項目以進行匯總。

分析及回報 FID 資料

由於 FID 值的預期變異數，在製作 FID 報表時，請務必查看值的分佈情形，並將重點放在更高的百分位數。

雖然所有 Core Web Vitals 門檻的百分比選項都是第 75 個，特別是 FID 時，我們強烈建議查看第 95 至 99 個百分位數，因為這會影響使用者在您網站上採用的首次體驗不佳。並顯示最需要改善的部分。

就算是按裝置類別或類型區隔報表也一樣。舉例來說，如果您分別針對電腦和行動裝置分別執行報表，最重視的桌機 FID 值應為電腦使用者的第 95 至 99 個百分位數，而您在行動裝置中最重視的 FID 值應為行動裝置使用者的第 95 至 99 個百分位數。

如何改善 FID

想瞭解如何改善這項指標，請參閱最佳化 FID 的完整指南。

變更記錄

有時用於測量指標的 API 中會發現錯誤，有時在指標本身的定義中也會發現錯誤。因此，有時需要進行變更，這些變更可能會在內部報表和資訊主頁中顯示為改善或迴歸。

為協助您管理這項情況，我們會在這個變更記錄中顯示這些指標的導入方式或定義所做的所有變更。

如果對這些指標有任何意見，歡迎透過 web-vitals-feedback Google 群組提供。