我們都知道給人留下良好的第一印象是多麼重要。這不僅對於結識新朋友十分重要，在網絡上塑造體驗時也同樣重要。
在網絡上，良好的第一印象能夠決定人們會成爲忠實用戶，還是從此一去不回頭。問題在於，什麼樣的體驗能留下良好印象，而您又要如何衡量您給用戶留下了怎樣的印象？
在網絡上，第一印象可以有很多不同的形式，我們會對網站的設計和視覺吸引力形成第一印象，也會對網站的速度和響應度形成第一印象。
雖然很難通過網頁 API 來衡量用戶對網站設計的喜愛程度，但網頁 API 卻可以輕鬆測量網站速度和響應度！
用戶對您的網站加載速度的第一印象可以通過First Contentful Paint 首次內容繪製 (FCP)進行測量。但是，您的網站在屏幕上繪製像素的速度只是其中一部分，同樣重要的還有當用戶試圖與這些像素進行交互時，您的網站響應度有多高！
首次輸入延遲 (FID) 指標有助於衡量您的用戶對網站交互性和響應度的第一印象。
什麼是 FID？ #
FID 測量從用戶第一次與頁面交互（例如當他們單擊鏈接、點按按鈕或使用由 JavaScript 驅動的自定義控件）直到瀏覽器對交互作出響應，並實際能夠開始處理事件處理程序所經過的時間。
怎樣算是良好的 FID 分數？ #
爲了提供良好的用戶體驗，網站應該努力將首次輸入延遲設控制在100 毫秒或以內。爲了確保您能夠在大部分用戶的訪問期間達成建議目標值，一個良好的測量閾值爲頁面加載的第 75 個百分位數，且該閾值同時適用於移動和桌面設備。
FID 詳情 #
作爲編寫事件響應代碼的開發者，我們通常會假定代碼會在事件發生時立即運行。但作爲用戶，我們都常常面臨相反的情況，當我們在手機上加載了一個網頁並試圖與網頁交互，接着卻因爲網頁沒有任何反應而感到沮喪。
一般來說，發生輸入延遲（又稱輸入延時）是因爲瀏覽器的主線程正忙着執行其他工作，所以（還）不能響應用戶。可能導致這種情況發生的一種常見原因是瀏覽器正忙於解析和執行由您的應用程序加載的大型 JavaScript 文件。在此過程中，瀏覽器不能運行任何事件偵聽器，因爲正在加載的 JavaScript 可能會讓瀏覽器去執行其他工作。
問題
請看以下這條典型的網頁加載時間軸：
上方的可視化圖表中顯示的是一個頁面，該頁面正在發出數個網絡請求來獲取資源（多爲 CSS 和 JS 文件），這些資源下載完畢後，會在主線程上進行處理。
這就導致主線程會階段性地處於忙碌狀態（在圖中表示爲米黃色任務塊）。
較長的首次輸入延遲通常發生在首次內容繪製 (FCP)和Time to Interactive 可交互時間 (TTI)之間，因爲在此期間，頁面已經渲染出部分內容，但交互性還尚不可靠。爲了說明這種情況的發生緣由，我們在時間軸中加入了 FCP 和 TTI：
您可能已經注意到 FCP 和 TTI 之間有相當長的一段時間（包括三段長任務），如果用戶在這段時間內嘗試與頁面進行交互（例如單擊一個鏈接），那麼從瀏覽器接收到單擊直至主線程能夠響應之前就會有一段延遲。
請看如果用戶在最長的任務剛開始時就嘗試與頁面進行交互會發生什麼：
因爲輸入發生在瀏覽器正在運行任務的過程中，所以瀏覽器必須等到任務完成後才能對輸入作出響應。瀏覽器必須等待的這段時間就是這位用戶在該頁面上體驗到的 FID 值。
如果交互沒有事件偵聽器怎麼辦？ #
FID 測量接收到輸入事件的時間點與主線程下一次空閒的時間點之間的差值。這就意味着**即使在尚未註冊事件偵聽器的情況下，**FID 也會得到測量。這是因爲許多用戶交互的執行並不需要事件偵聽器，但一定需要主線程處於空閒期。
例如，在對用戶交互進行響應前，以下所有 HTML 元素都需要等待主線程上正在進行的任務完成運行：
- 文本字段、複選框和單選按鈕 (
<input>、<textarea>) - 下拉選擇列表（
<select>） - 鏈接 (
<a>)
爲什麼只考慮首次輸入？ #
雖然任何輸入延遲都可能導致糟糕的用戶體驗，但我們主要建議您測量首次輸入延遲，原因如下：
- 首次輸入延遲將會是用戶對您網站響應度的第一印象，而第一印象對於塑造我們對網站質量和可靠性的整體印象至關重要。
- 我們現如今在網絡上看到的最大的交互性問題發生在頁面加載期間。因此，我們認爲首先側重於改善網站的首次用戶交互將對改善網絡的整體交互性產生最大的影響。
- 我們推薦網站針對較高的首次輸入延遲採取的解決方案（代碼拆分、減少 JavaScript 的預先加載量等）不一定與針對頁面加載後輸入延遲緩慢的解決方案相同。通過分離這些指標，我們將能夠爲網頁開發者提供更確切的性能指南。
哪些算是首次輸入？ #
FID 是測量頁面加載期間響應度的指標。因此，FID 只關注不連續操作對應的輸入事件，如點擊、輕觸和按鍵。
其他諸如滾動和縮放之類的交互屬於連續操作，具有完全不同的性能約束（而且，瀏覽器通常能夠通過在單獨的線程上執行這些操作來隱藏延遲）。
換句話說，FID 側重於RAIL 性能模型中的 R（響應度），而滾動和縮放與 A（動畫）更爲相關，因此這些操作的性能質量應該單獨進行評估。
如果用戶始終沒有與您的網站進行交互怎麼辦？ #
並非所有用戶都會在每次訪問您的網站時進行交互。而且也並不是所有交互都與 FID 相關（如上一節所述）。此外，一些用戶的首次交互會處於不利的時間段內（當主線程長時間處於繁忙時），而另一些用戶的首次交互會處於有利的時間段內（當主線程完全空閒時）。
這意味着有些用戶將沒有 FID 值，有些用戶的 FID 值較低，而有些用戶的 FID 值可能較高。
您對 FID 的跟蹤、報告和分析方式可能與您慣常使用的其他指標十分不同。下一節將說明相應的最佳做法。
爲什麼只考慮輸入延遲？ #
如上所述，FID 只測量事件處理過程中的"延遲"。FID 既不測量事件處理本身所花費的時間，也不測量瀏覽器在運行事件處理程序後更新用戶界面所花費的時間。
雖然這些時間對用戶來說非常重要，也確實會影響用戶體驗，但這些時間並不包括在該項指標內，因爲這樣的做法可能會激勵開發者加入變通方案，並因此導致體驗變得更加糟糕，這裏的意思是說，開發者可以將事件處理程序邏輯封裝在一個異步回調中（通過setTimeout()或requestAnimationFrame()），從而將邏輯與事件關聯的任務分離。最終的結果雖然能夠提升指標分數，但會使用戶感知到的響應速度變慢。
不過，雖然 FID 只測量事件延時的"延遲"部分，但想要對事件生命週期進行更多跟蹤的開發者可以使用事件計時 API來實現這一想法。如需更多詳情，請參閱自定義指標的相關指導。
如何測量 FID #
FID 是一個只能進行實際測量的指標，因爲該項指標需要真實用戶與您的頁面進行交互。您可以使用以下工具測量 FID。
實測工具 #
在 JavaScript 中測量 FID #
要在 JavaScript 中測量 FID，您可以使用事件計時 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 要更爲複雜。詳情請見下文：
在上方的示例中，first-input條目的延遲值是通過獲取條目的startTime和processingStart時間戳之間的差值來測量的。在大多數情況下，這個差值就是 FID 值，然而，並非所有first-input條目都能夠用來測量 FID。
以下部分列出了 API 報告的內容與指標計算方式之間的差異。
指標和 API 之間的差異 #
- API 會爲在後臺選項卡中加載的頁面分發
first-input條目，但在計算 FID 時應忽略這些頁面。 - 如果頁面在首次輸入發生前轉移到後臺，API 也會分發
first-input條目，但在計算 FID 時仍應忽略這些頁面（只有當頁面始終處於前臺時才考慮輸入）。 - 當頁面通過往返緩存恢復時，API 不會報告
first-input條目，但在這些情況下應該測量 FID，因爲這對用戶來說是多次不同的頁面訪問體驗。 - API 不會報告 iframe 中的輸入，但要想正確測量 FID，您應該考慮這些輸入。子框架可以使用 API 將這些輸入的
first-input條目報告給父框架來進行聚合。
開發者不必記住所有這些細微差異，而是可以使用web-vitals JavaScript 庫來測量 FID，庫會自行處理這些差異（在可能的情況下）：
import {getFID} from 'web-vitals';
// 當 FID 可用時立即進行測量和記錄。
getFID(console.log);您可以參考getFID)的源代碼，瞭解如何在 JavaScript 中測量 FID 的完整示例。
web-vitals庫的
侷限性部分。
分析和報告 FID 數據 #
由於 FID 值的預期差異，您必須在報告 FID 時查看值的分佈並關注較高的百分位數，這一點至關重要。
雖然所有核心 Web 指標閾值的優選百分位數是第 75 個百分位數，但具體到 FID，我們仍然強烈建議您將閾值設置在第 95-99 個百分位數，因爲這些百分位數對應於用戶在您網站上經歷的特別糟糕的首次體驗，因而也能夠讓您獲知最需要進行改進的地方。
即使您按設備類別或類型對報告進行細分，也應該這樣做。例如，如果您分別對桌面端和移動端進行報告，那麼您最應該關注的桌面端 FID 值應該是桌面端用戶的第 95-99 個百分位數，而您最應該關注的移動端 FID 值應該是移動端用戶的第 95-99 個百分位數。
如何改進 FID #
要了解如何改進某個特定網站的 FID，您可以運行一次燈塔性能審計，並留心查看審計建議的各種具體機會。
雖然 FID 是一項實際指標（而燈塔是一個實驗室指標工具），但改進 FID 的指導方向與改進總阻塞時間 (TBT)這項實驗室指標的指導方向相同。
如需深入瞭解如何改進 FID，請參閱優化 FID。有關其他能夠改進 FID 的單個性能技巧的進一步指導，請參閱：