Interaction to Next Paint (INP)

Jeremy Wagner

Barry Pollard

發布日期：2022 年 5 月 6 日，上次更新日期：2025 年 9 月 9 日

Chrome 使用資料顯示，使用者在網頁上 90% 的時間都花在網頁載入後，因此請務必在整個網頁生命週期中仔細評估回應性。這就是 INP 指標的評估內容。

良好的回應性表示網頁能迅速回應互動。網頁回應互動時，瀏覽器會在下一個繪製的影格中顯示視覺回饋。舉例來說，視覺回饋會告訴您加入線上購物車的商品是否確實已加入、行動版導覽選單是否已開啟、伺服器是否正在驗證登入表單內容等等。

有些互動自然會比其他互動耗時，但對於特別複雜的互動，請務必快速呈現一些初步的視覺回饋，讓使用者知道正在進行某些作業。瀏覽器要繪製的下一個影格，就是執行這項操作的最早時機。

因此，「與下一個顯示的內容互動」指標並非要評估互動的所有最終影響 (例如來自其他非同步作業的網路擷取和 UI 更新)，而是要評估下一個繪製作業遭到封鎖的時間。如果視覺回饋延遲，使用者可能會認為網頁回應速度不夠快，而 INP 的開發目的，就是協助開發人員評估這部分的使用者體驗。

在下列影片中，右側的範例會立即提供視覺回饋，指出手風琴正在開啟。左側範例顯示回應速度緩慢，以及這如何導致使用者體驗不佳。

本指南說明 INP 的運作方式、如何評估 INP，以及如何透過相關資源改善 INP。

什麼是 INP？

INP 指標會觀察使用者造訪網頁期間，所有點擊、輕觸和鍵盤互動的延遲時間，評估網頁對於使用者互動的整體回應時間。最終 INP 值是指觀測到的最長互動時間，忽略離群值。

「互動」是指在同一個邏輯使用者手勢期間觸發的一組事件處理常式。舉例來說，觸控螢幕裝置上的「輕觸」互動包含多個事件，例如 pointerup、pointerdown 和 click。互動可由 JavaScript、CSS、內建瀏覽器控制項 (例如表單元素) 或上述項目的組合驅動。

互動延遲時間是指一組事件處理常式中，單一最長的持續時間。這組事件處理常式會驅動互動，從使用者開始互動到瀏覽器下一次能夠繪製影格為止。在極少數情況下，可能沒有要繪製的影格，但互動會在瀏覽器能夠繪製影格時結束。

良好的 INP 分數是多少？

很難為回應情形指標加上「良好」或「不佳」等標籤。一方面，您希望鼓勵開發人員採用以良好回應性為優先的開發做法。另一方面，您必須考量使用者用來設定可達成開發目標的裝置功能差異極大。

為確保提供良好的回應式使用者體驗，建議您以在實際環境中記錄到的網頁載入時間第 75 個百分位數做為門檻，並依行動裝置和電腦裝置區隔：

• 如果 INP 低於或等於 200 毫秒，表示網頁反應速度良好。
• 如果 INP 介於 200 毫秒以上和 500 毫秒以下或等於 500 毫秒，表示網頁回應速度有待加強。
• 如果 INP 高於 500 毫秒，表示網頁的回應速度緩慢。

互動包含哪些內容？

互動性的主要驅動程式通常是 JavaScript，但瀏覽器也會透過不由 JavaScript 驅動的控制項提供互動性，例如核取方塊、圓形按鈕和由 CSS 驅動的控制項。

由於 INP 的用途，系統只會觀察下列互動類型：

• 使用滑鼠點選。
• 輕觸觸控螢幕裝置。
• 按下實體鍵盤或螢幕小鍵盤上的按鍵。

互動發生在主要文件中，或文件中嵌入的 iframe 中，例如點選嵌入影片的「播放」按鈕。使用者不會知道 iframe 內有什麼內容，因此需要測量 iframe 內的 INP，才能評估頂層網頁的使用者體驗。由於 JavaScript Web API 無法存取 iframe 的內容，這可能會顯示 CrUX 和 RUM 之間的差異

互動可能包含多個事件。舉例來說，按鍵事件包含 keydown、keypress 和 keyup 事件。輕觸互動包含 pointerup 和 pointerdown 事件。互動中時間最長的事件，會計入互動的總延遲時間。

如圖所示，INP 的「處理時間」包含該影格內的所有事件處理常式回呼。因此，輸入延遲是指處理互動的任何回呼之前所需的時間；處理時間是指執行所有回呼所需的時間；顯示延遲是指執行回呼後，到畫面顯示在使用者螢幕上所需的時間。

使用者離開網頁時，系統會計算該網頁的 INP。結果是單一值，代表網頁在整個生命週期中的整體回應速度。INP 分數越低，表示網頁回應使用者輸入內容的可靠性越高。

INP 與首次輸入延遲 (FID) 有何不同？

INP 是 First Input Delay (FID) 的後續指標。雖然兩者都是回應速度指標，但 FID 只會評估網頁首次互動的輸入延遲時間。INP 會觀察網頁上的所有互動，從輸入延遲時間開始，到執行事件處理常式所需的時間，最後到瀏覽器繪製下一個影格為止，藉此改善 FID。

這些差異代表 INP 和 FID 是不同類型的即時回應指標。FID 是載入回應指標，用於評估網頁給使用者的第一印象；INP 則是更可靠的整體回應指標，無論互動發生在網頁生命週期的哪個階段，都能提供參考價值。

如果沒有回報 INP 值，該怎麼辦？

網頁可能不會傳回 INP 值。這可能由許多因素造成，包括：

• 頁面已載入，但使用者從未點按、輕觸或按下鍵盤上的按鍵。
• 網頁已載入，但使用者與網頁互動時使用的手勢未納入評估範圍，例如捲動或將游標懸停在元素上。
• 網頁是由機器人存取，例如搜尋檢索器或無頭瀏覽器，但這些機器人並未編寫與網頁互動的指令碼。

如何評估 INP

您可以在實際環境和實驗室中評估 INP，前提是您能模擬真實的使用者互動。

在欄位中

理想上，最佳化 INP 的過程應從實際工作環境資料開始。在最佳情況下，Real User Monitoring (RUM) 的欄位資料不僅會提供網頁的 INP 值，還會提供情境資料，指出導致 INP 值的特定互動、互動發生在網頁載入期間還是之後、互動類型 (點擊、按鍵或輕觸)，以及其他有價值的時間資訊，協助您找出影響回應速度的互動部分。

如果您的網站符合 Chrome 使用者體驗報告 (CrUX) 的收錄資格，您就能透過 PageSpeed Insights 中的 CrUX，快速取得 INP 的現場資料 (以及其他網站使用體驗核心指標)。您至少可以取得網站 INP 的來源層級圖片，但在某些情況下，也可以取得網址層級資料。

不過，雖然 CrUX 可以告訴您有問題，但無法說明問題原因。RUM 解決方案可協助您發掘更多有關網頁、使用者或使用者互動的詳細資料，這些資料會遇到回應性問題。將 INP 歸因於個別互動，可避免猜測和浪費心力。

實驗室

理想情況下，一旦有現場資料顯示網頁互動緩慢，您就應該在實驗室中開始測試。有了欄位資料，在實驗室中重現有問題的互動就會簡單許多。

不過，您可能沒有欄位資料。雖然部分實驗室工具可以測量 INP，但實驗室測試期間網頁的 INP 值，取決於測量期間執行的互動。使用者行為難以預測且變化多端，因此在實驗室進行測試時，可能無法像現場資料一樣，找出問題互動。此外，部分實驗室工具只會觀察網頁載入情形，不會有任何互動，因此不會回報網頁的 INP。在這種情況下，總封鎖時間 (TBT) 可能是 INP 的合理替代指標，但本身並非 INP 的替代指標。

雖然實驗室工具在評估網頁的 INP 時有其限制，但您可以採取一些策略，在實驗室中重現緩慢的互動。策略包括遵循常見的使用者流程，並在過程中測試互動，以及在網頁載入時 (主執行緒通常最忙碌) 與網頁互動，以便找出使用者體驗關鍵階段的緩慢互動。

在 JavaScript 中評估 INP

如要在 JavaScript 中評估 INP，您需要評估所有互動的事件時間，然後在網頁卸載時，取所有這些互動的第 98 個百分位數。您可以參閱 web vitals JavaScript 程式庫原始碼，其中包含 INP 計算方式的參考實作。

在大多數情況下，網頁卸載時的目前 INP 值就是該網頁的最終 INP 值，但下一節會說明幾個重要的例外狀況。在 Web API 的限制內，web vitals JavaScript 程式庫會盡可能考量這些因素。

指標與 API 的差異

• event根據預設，效能觀察工具不會回報低於 104 毫秒的項目。使用 durationThreshold 參數註冊效能觀察器時，可以變更這個預設值，但最小值為 16 毫秒。因此建議您也觀察 first-input 項目，這也是「事件時間」項目，但即使持續時間少於 durationThreshold，也保證可觀察到。這有助於確保有互動的網頁一律會回報 INP 值。
• 從技術上來說，如要完美計算百分位數，必須將所有樣本保留在記憶體中，這可能需要高昂的成本。不過，您只要保留一小份最差 N 次互動的清單，就能估算百分位數，尤其是 p98 等非常高的百分位數。10 是常見的選擇。
• 如果頁面是從往返快取還原，INP 值應重設為零，因為使用者會將此視為不同的網頁造訪。
• API 不會回報 iframe 內發生的互動的 event 項目，但指標會回報，因為這些項目是網頁使用者體驗的一部分。這會顯示為 CrUX 和 RUM 之間的差異。如要正確評估 INP，請考慮這些因素。子框架可以使用 API，將 event-timing 項目回報給父框架。

除了上述例外狀況，INP 還會測量整個網頁的生命週期，因此更加複雜：

• 使用者可能會長時間開啟分頁，例如數天、數週或數月。事實上，使用者可能永遠不會關閉分頁。
• 在行動作業系統上，瀏覽器通常不會為背景分頁執行網頁卸載回呼，因此難以回報「最終」值。

如要處理這類情況，除了網頁卸載時 (visibilitychange 事件涵蓋這兩種情況)，網頁在背景執行時也應回報 INP。接收這項資料的 Analytics 系統隨後必須在後端計算最終 INP 值。

開發人員不必自行記憶及處理所有這些情況，而是可以使用 web-vitals JavaScript 程式庫評估 INP，該程式庫會考量上述所有情況 (iframe 除外)：

import {onINP} from 'web-vitals';

// Measure and log INP in all situations
// where it needs to be reported.
onINP(console.log);

如何改善 INP

我們提供一系列最佳化 INP 的指南，協助您找出實際環境中速度緩慢的互動，並運用實驗室資料找出原因並加以改善。

變更記錄

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

為協助您管理這項異動，我們會在變更記錄中列出這些指標的導入或定義異動。

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

學以致用