First Input Delay (FID)

Philip Walton

我們都知道第一印象非常重要。這項技術對於結交新朋友很重要，在網路上建構體驗時也很重要。

在網路上，良好的第一印象是決定使用者是否會成為忠實顧客的關鍵。問題是，如何留下好印象？以及如何評估您可能帶給使用者的印象？

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

雖然很難使用 Web API 評估使用者對網站設計的喜好程度，但評估網站的速度和回應能力卻不難！

您可以使用首次顯示內容所需時間 (FCP)，評估使用者對網站載入速度的第一印象。但網站將像素繪製到畫面的速度只是其中一環。同樣重要的是，當使用者嘗試與這些像素互動時，網站的反應速度！

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

什麼是 FID？

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

良好的 FID 分數是多少？

為了提供良好的使用者體驗，網站應力求讓首次輸入延遲時間低於 100 毫秒。為確保你能為多數使用者提供此等級的體驗，建議以頁面載入的第 75 百分位數作為衡量閾值，並分別針對行動裝置與桌面裝置進行分析。

FID 詳細資料

身為編寫程式碼來回應事件的開發人員，我們通常會假設程式碼會在事件發生後立即執行。但身為使用者，我們經常遇到相反的情況：在手機上載入網頁後，嘗試與網頁互動，卻發現毫無反應，令人感到沮喪。

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

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

上圖顯示網頁正在對資源發出幾項網路要求 (很可能是 CSS 和 JS 檔案)，且這些資源下載完成後，會在主執行緒上處理。

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

通常在First Contentful Paint (FCP) 和Time to Interactive (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 (網站體驗核心指標報表)
• web-vitals JavaScript 程式庫

在 JavaScript 中評估 FID

如要在 JavaScript 中評估首次輸入延遲時間，可以使用 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 的延遲值，方法是取得項目 startTime 和 processingStart 時間戳記之間的差異。在大多數情況下，這會是 FID 值；不過，並非所有 first-input 項目都適用於測量 FID。

以下列出 API 報表與指標計算方式的差異。

指標與 API 的差異

• API 會針對在背景分頁中載入的網頁傳送 first-input 項目，但在計算 FID 時應忽略這些網頁。
• 如果網頁在發生第一次輸入事件前已進入背景，API 也會傳送 first-input 項目，但在計算首次輸入延遲時，也應忽略這些網頁 (只有在網頁全程處於前景時，才會將輸入事件納入考量)。
• 網頁從往返快取還原時，API 不會回報 first-input 項目，但使用者會將這些情況視為不同的網頁造訪，因此應測量首次輸入延遲時間。
• API 不會回報 iframe 內發生的輸入內容，但指標會回報，因為這些內容是網頁使用者體驗的一部分。這可能會顯示為 CrUX 和 RUM 之間的差異。如要正確評估 FID，請將這些因素納入考量。子影格可以使用 API，將 first-input 項目回報給父影格進行匯總。

分析及回報 FID 資料

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

雖然所有網站體驗核心指標門檻的百分位數選擇都是第 75 個百分位數，但我們仍強烈建議您查看第 95 個至第 99 個百分位數的 FID，因為這些百分位數對應的是使用者在您網站上遇到的特別糟糕的首次體驗。並顯示最需要改進的領域。

即使您依裝置類別或類型區隔報表，這項規定仍然適用。舉例來說，如果您分別為電腦和行動裝置執行報表，電腦使用者第 95 至 99 個百分位數的 FID 值，應是您最重視的電腦值；行動裝置使用者第 95 至 99 個百分位數的 FID 值，應是您最重視的行動裝置值。

如何改善 FID

如需最佳化首次輸入延遲時間的完整指南，請參閱這篇文章，瞭解如何運用各種技巧改善這項指標。

變更記錄

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

為方便您管理，這些指標的實作或定義如有任何變更，都會顯示在變更記錄中。

如要對這些指標提供意見，請前往 web-vitals-feedback Google 群組。