我們都知道良好的第一印像很重要。認識新朋友相當重要，在網路上打造體驗也很重要。
在網路上，良好的第一印象可能會影響使用者成為忠實使用者，或使用者不再回訪與回訪觀眾之間的差異。問題在於 怎樣才算好印象？又該如何評估使用者可能會留下什麼樣的印象？
在網路上，「第一次曝光」所呈現的內容可能非常多元，我們會對網站設計和視覺效果的第一印象，以及對網站設計速度和回應速度的第一印象。
儘管使用網頁 API 評估網站設計對使用者的喜歡程度並不高，但想要評估網站的速度和回應能力，卻是相當困難的事！
「第一次曝光」使用者可透過首次顯示內容繪製 (FCP) 來評估網站載入速度。但網站繪製像素的速度只是故事的一部分當使用者嘗試與這些像素互動時，網站的回應速度也同樣重要！
「首次輸入延遲時間」(FID) 指標有助於評估使用者對網站互動性和回應度的第一印象。
什麼是 FID？
FID 會測量從使用者首次與網頁互動 (也就是使用者點選連結、輕觸按鈕或使用自訂的 JavaScript 控制項) 到瀏覽器實際能夠根據該互動開始處理事件處理常式所需的時間。
什麼是良好的 FID 分數？
為提供良好的使用者體驗，網站應力求將首次輸入延遲時間設為 100 毫秒以下。為確保大部分使用者都能達成這個目標，評估的理想門檻為 75 個百分位數，在行動裝置和電腦裝置上區隔開來。
FID 詳細資訊
由於開發人員編寫程式碼來回應事件，我們通常會假設程式碼會在事件發生後立即執行。但使用者也經常遇到相反的狀況，也就是在手機中載入網頁、嘗試與網頁互動，然後在沒有任何發生的情況下感到沮喪。
一般來說，輸入延遲 (也就是輸入延遲時間) 是因為瀏覽器的主執行緒忙於進行其他作業，因此無法回應使用者。造成此情況的常見原因之一，是瀏覽器忙於剖析並執行應用程式載入的大型 JavaScript 檔案。由於載入的 JavaScript 可能會指示其執行其他動作，因此系統無法執行任何事件監聽器。
請參考以下的一般網頁載入時間軸：
上述視覺化呈現的網頁正在對資源發出幾個網路要求 (很可能是 CSS 和 JS 檔案)，並在資源下載完成後，於主執行緒上進行處理。
這會導致主要執行緒暫時忙碌，而此期間以米色的工作區塊表示。
首次輸入延遲通常會發生在首次顯示內容所需時間 (FCP) 到互動時間 (TTI) 之間，因為頁面已轉譯部分內容，但尚未穩定互動。我們在時間軸中新增了 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 只測量事件處理時的「延遲」。系統不會測量事件處理時間本身，或執行事件處理常式後更新使用者介面所需的時間。
雖然這個時間對使用者來說很重要，且「確實」會影響體驗，但這項指標並未納入這項指標，因為這樣做可能會激勵開發人員加入解決方法，因為這樣反而會導致體驗較差。也就是說，他們可以將事件處理常式邏輯納入非同步回呼 (透過 setTimeout() 或 requestAnimationFrame())，以便將其與事件相關任務區隔開來。結果會提升指標分數，但使用者感知的反應速度較慢。
不過，雖然 FID 只測量事件延遲時間的「延遲」部分，但開發人員如果想要追蹤更多事件生命週期，可以使用 Event Timing API。詳情請參閱自訂指標指南。
如何測量 FID
FID 是只能在欄位中評估的指標，因為 FID 需要實際使用者與您的網頁互動。您可以使用下列工具測量 FID。
現場工具
在 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 項目的延遲值是根據項目的 startTime 和 processingStart 時間戳記之間的差距進行測量。在多數情況下，這會是 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項目回報給上層框架進行匯總。
開發人員不必記住所有細微的差異，只要使用 web-vitals JavaScript 程式庫測量 FID 即可。這個程式庫會盡可能處理這些差異 (請注意，此處不會討論 iframe 問題)：
import {onFID} from 'web-vitals';
// Measure and log FID as soon as it's available.
onFID(console.log);
如需在 JavaScript 中評估 FID 的完整範例，請參閱 onFID() 的原始碼。
分析 FID 資料並產生報表
由於 FID 值的預期變異數，因此在回報 FID 時，請務必查看值的分佈情形，並著重於較高的百分位數。
雖然所有網站體驗核心指標門檻的百分位數選項為 75，特別是針對 FID，我們仍然強烈建議您查看第 95 至 99 個百分位數，因為這會對應到使用者在網站上特別感到不滿意的體驗。也會顯示哪些部分需要改善
就算是按裝置類別或類型區隔報表也是如此。舉例來說，如果您分別針對電腦和行動裝置分別執行報表，您最重視的 FID 值應為電腦使用者的第 95 至 99 個百分位數，您最重視的 FID 值應該是行動裝置使用者的第 95% 到 99%。
如何改善 FID
您可以參考最佳化 FID 的完整指南，瞭解改善這項指標的技巧。
變更記錄
有時候，我們在測量指標的 API 中會發現錯誤，有時則在指標本身定義中發現錯誤。因此，有時仍須做出變更，而這些變更可能會在內部報表和資訊主頁中顯示為改善或迴歸。
為協助您管理，這些指標的導入或定義的所有變更，都會顯示在這份變更記錄中。
如果您對這些指標有任何意見，可以前往 web-vitals-feedback Google 群組提出。