精品軟體與實用教程
我們都知道給人留下良好的第一印像是多麼重要。這不僅對認識新朋友十分重要，在網路上塑造體驗時也同樣重要。
在網路上，良好的第一印象能夠決定人們會成為忠實用戶，還是從此一去不回頭。問題在於，什麼樣的體驗能留下良好印象，而您又要如何衡量您給使用者留下了怎樣的印象？
在網路上，第一印象可以有很多不同的形式，我們會對網站的設計和視覺吸引力形成第一印象，也會對網站的速度和響應度形成第一印象。
雖然很難透過網頁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 數據分析和報告的部分內容以了解更多相關資訊。
如果互動沒有事件偵聽器怎麼辦？
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條目的延遲值是透過取得條目的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 的完整範例。
分析和報告FID 數據
由於FID 值的預期差異，您必須在報告FID 時查看值的分佈並關注較高的百分位數，這一點至關重要。
雖然所有核心Web 指標閾值的優選百分位數是第75 個百分位數，但具體到FID，我們仍然強烈建議您將閾值設定在第95-99 個百分位數，因為這些百分位數對應於使用者在您網站上經歷的特別糟糕的首次體驗，因而也能夠讓您獲知最需要進行改進的地方。
即使您按設備類別或類型對報告進行細分，也應該這樣做。例如，如果您分別對桌面端和行動端進行報告，那麼您最應該關注的桌面端FID 值應該是桌面端用戶的第95-99 個百分位數，而您最應該關注的行動端FID 值應該是行動端用戶的第95-99 個百分位數。
如何改進FID
要了解如何改進某個特定網站的FID，您可以執行一次燈塔性能審計，並留心查看審計建議的各種具體機會。
雖然FID 是一項實際指標（而燈塔是一個實驗室指標工具），但改善FID 的指導方向與改進總阻塞時間(TBT)這項實驗室指標的指導方向相同。
如需深入了解如何改善FID，請參閱優化FID。其他能夠改進LCP 的單一效能技巧的進一步指導，請參閱：
