First Input Delay (FID)

Philip Walton

瀏覽器支援

• 76
• 79
• 89
• x

資料來源

警告：First Input Delay (FID) 已不再是 Core Web Vitals 指標，而是改由 Interaction to Next Paint (INP) 指標取代。因此，FID 已於 2024 年 9 月 9 日停止支援。現在您應著重於 INP。

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

在網路上，良好的第一印象可以讓使用者成為忠實使用者，或是離開並永不回頭。問題是，什麼樣的內容會給人留下良好印象？您又該如何評估使用者可能會對您產生什麼樣的印象？

在網路上，第一印象可以有很多種形式，包括網站的設計和視覺吸引力，以及網站速度和回應速度的第一印象。

雖然很難評估使用者對網站設計的喜愛程度，但評估網站速度和回應速度卻很容易！

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

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

什麼是 FID？

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

什麼是良好的 FID 分數？

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

注意： 如要進一步瞭解這項最佳化建議背後的研究和方法，請參閱「定義 Core Web Vitals 指標門檻」

。

FID 詳細資訊

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

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

FID 只會評估事件處理的「延遲時間」。它不會評估事件處理時間總長度，也不會評估瀏覽器在執行事件處理常式後更新 UI 所需的時間。雖然這段時間確實會影響使用者體驗，但將這段時間納入 FID 的一部分，會促使開發人員以非同步方式回應事件，雖然這麼做可改善指標，但可能會讓使用者體驗變差。詳情請參閱下方的為何只考量輸入延遲。

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

上方的示意圖顯示網頁正在為資源 (很可能是 CSS 和 JS 檔案) 提出幾個網路要求，而這些資源下載完成後，就會在主執行緒中處理。

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

首次輸入延遲時間通常會發生在首次顯示內容所需時間 (FCP) 和互動準備時間 (TTI) 之間，因為頁面已轉譯部分內容，但尚未可靠地進行互動。為了說明這種情況的發生原因，我們已將 FCP 和 TTI 新增至時間軸：

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

請考慮以下情況：如果使用者在最長工作階段開始時嘗試與網頁互動，會發生什麼事：

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

注意： 在這個例子中，使用者剛好在主執行緒最繁忙期間的開頭與網頁互動。如果使用者在空閒期間稍早與網頁互動，瀏覽器就會立即回應。輸入延遲時間的差異，凸顯出在回報指標時，觀察 FID 值分佈的重要性。如要進一步瞭解這項功能，請參閱下文關於分析及回報 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。

注意： FID 需要真實使用者，因此無法在實驗室中評估。不過，總阻斷時間 (TBT) 指標可在實驗室中進行評估，與實地測試的 FID 有良好關聯，而且還能擷取影響互動性的問題。在實驗室中改善 TBT 的最佳化調整，也應能改善使用者的 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});

警告： 此程式碼說明如何將 first-input 項目記錄到控制台，並計算其延遲時間。不過，在 JavaScript 中測量 FID 會比較複雜。詳情請見下文：

在上述範例中，系統會根據項目的 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，請考慮這些因素。子影格可以使用 API，將其 first-input 項目回報給父影格，以便匯總。

注意： 在某些情況下 (例如跨來源 iframe)，JavaScript 無法評估 FID。

分析及回報 FID 資料

由於 FID 值會出現預期的變化，因此在回報 FID 時，請務必查看值的分布情形，並著重於較高的百分位數。

雖然所有 Core Web Vitals 門檻的百分位數選擇為 75，但我們仍強烈建議您針對 FID 查看 95 到 99 百分位數，因為這會對應到使用者對網站的初次體驗特別差的情況。並顯示最需要改善的部分。

即使您依裝置類別或類型區隔報表，也一樣。舉例來說，如果您為電腦和行動裝置分別執行報表，電腦上最在意的 FID 值應為電腦使用者的第 95 到 99 百分位數，而行動裝置上最在意的 FID 值應為行動裝置使用者的第 95 到 99 百分位數。

如何改善 FID

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

變更記錄

有時，我們會在用於評估指標的 API 中發現錯誤，有時也會在指標定義中發現錯誤。因此，有時必須進行變更，這些變更可能會在內部報表和資訊主頁中顯示為改善或回歸。

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

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