改善與下一個顯示的內容的互動方式

瞭解如何最佳化網站與下一個顯示畫面的互動方式。

「與下一個顯示內容的互動 (INP)」是穩定的 Core Web Vitals 指標，藉由觀察使用者造訪網頁期間，所有符合條件的互動在一段時間內，評估網頁與使用者互動的整體回應時間。最終 INP 值是觀察到的最長互動 (有時忽略離群值)。

為了提供良好的使用者體驗，網站應力求與下一個顯示畫面互動 (互動時間不超過 200 毫秒)。為確保大部分使用者都能達成此目標，建議您評估網頁載入的第 75 個百分位數，並區隔行動裝置和電腦裝置。

視網站而定，互動可能不多，例如網頁大多包含文字和圖片，互動元素較少。而對於文字編輯器或遊戲等網站，則可能帶來數十甚至數千次的互動。無論是哪種 INP 都很高，使用者體驗都會有風險。

改善 INP 需要時間和心力，但獎勵更優異的使用者體驗。本指南將說明改善 INP 的方法。

找出導致 INP 不佳的原因

您必須先根據資料判斷網站的 INP 是否不佳或需要改善，才能修正互動速度緩慢的問題。取得相關資訊後，就可以進入研究室，開始診斷緩慢的互動情形，並設法找出解決方法。

尋找領域中的緩慢互動

理想情況下，最佳化 INP 的流程會從現場資料開始。最理想的情況是，即時使用者監控 (RUM) 供應商的欄位資料不僅提供網頁的 INP 值，還會提供關於 INP 值本身負責的特定互動、互動類型 (點擊、按鍵或觸控) 和其他寶貴資訊的情境資料。

如果您並非透過 RUM 供應商取得欄位資料，INP 欄位資料指南建議您透過 PageSpeed Insights使用 Chrome 使用者體驗報告 (CrUX) 來填補缺口。CrUX 是 Core Web Vitals 計畫的官方資料集，內含數百萬個網站 (包括 INP) 的指標概要摘要。然而，CrUX 通常不會提供從 RUM 供應商取得的比對內容資料，協助您分析問題。因此，我們仍建議網站盡可能使用 RUM 供應商，或導入自己的 RUM 解決方案來補強 CrUX 提供的功能。

在研究室中診斷緩慢的互動情形

理想情況下，一旦有可表明互動緩慢情形的實際資料，建議您先在研究室中進行測試。在缺少現場資料的情況下，可以運用一些策略，識別研究室中緩慢的互動。這類策略包括追蹤常見的使用者流程，並在過程中測試各種互動情形，以及在載入期間與網頁互動 (主要執行緒通常最忙碌的時候)，以便找出使用者體驗中關鍵部分的緩慢互動。

提升互動成效

發現緩慢的互動情形，且在研究室中手動重現後，下一步就是最佳化。互動可分為三個階段：

1. 輸入延遲，是從使用者與網頁互動時開始，並在互動事件回呼開始執行時結束。
2. 「處理時間長度」，包含事件回呼所需的執行時間。
3. 顯示延遲，這是瀏覽器顯示下一個影格所需的時間，內含互動的視覺結果。

這三個階段的總和是總互動延遲時間。每個互動階段都會產生一段總互動延遲的時間，因此請務必瞭解如何最佳化各個互動環節，盡可能讓互動過程盡可能縮短。

識別並縮短輸入延遲時間

使用者與網頁互動時，互動的第一部分是「輸入延遲」。視網頁上的其他活動而定，輸入的延遲時間可能較長。這可能是因為活動發生在主執行緒上 (可能是指令碼載入、剖析和編譯)、擷取處理、計時器函式，甚至是快速連續且彼此重疊的其他互動造成。

無論互動的輸入延遲時間為何，您都希望將輸入延遲時間降到最低，讓互動可以盡快開始執行事件回呼。

啟動期間指令碼評估與長時間工作之間的關係

在啟動期間，頁面生命週期中互動的一大關鍵。系統載入網頁時，一開始會先顯示，但請注意，即使頁面「已轉譯」，也不代表該網頁已經完成載入，視網頁需要完全正常運作的資源而定，使用者在網頁載入期間可能會嘗試與網頁互動。

網頁載入時，可能會延長互動的輸入延遲時間，就是指令碼評估。從網路擷取 JavaScript 檔案之後，瀏覽器在 JavaScript 可以執行之前還是需要處理，這項工作包括剖析指令碼以確保語法有效，並將其編譯成位元碼，再執行程式碼。

視指令碼的大小而定，這項工作可能會在主執行緒上產生很長的工作，導致瀏覽器無法回應其他使用者的互動。為了讓網頁在載入網頁時能回應使用者輸入的內容，務必瞭解如何減少網頁載入期間長時間完成工作的可能性，讓網頁保持簡單明瞭。

最佳化事件回呼

輸入延遲時間只是 INP 評估的第一部分。此外，您也必須確認為了回應使用者互動而執行的事件回呼能夠盡快完成。

經常產生給主執行緒

最佳化事件回呼的最佳通用建議是盡可能避免執行。不過，您的互動邏輯可能相當複雜，而且您能夠縮減其工作量。

如果發現網站有這種情況，接下來可嘗試將事件回呼中的工作拆分為不同的工作。這樣可以避免集體工作成為會封鎖主執行緒的長時間工作，讓原本在主執行緒上等待的其他互動更快執行。

setTimeout 是分割任務的一種方式，因為傳遞至它的回呼會在新工作中執行。您可以單獨使用 setTimeout，或將其用途提取至獨立函式，產生更符合人體工學的。

隨機產生比完全不產生收益更好，但產生到主要執行緒的細微差異是更加精細的，而且只有在更新使用者介面的事件回呼後，才會立即產生，讓算繪邏輯能更快執行。

用來加快算繪工作的速度

更進階的產生技術涉及在事件回呼中建構程式碼，限制要執行什麼動作，只能執行為下一個影格套用視覺更新所需的邏輯。其他郵件都可以延後到後續的工作。這樣不但能讓回呼變得輕快且靈活，而且不允許視覺化更新來封鎖事件回呼程式碼，從而改善互動的轉譯時間。

舉例來說，假設有一個 RTF 格式編輯器，會在輸入內容時設定文字格式，但也會根據你輸入的內容更新 UI 的其他部分 (例如字詞計數、醒目顯示拼字錯誤和其他重要的視覺回饋)。此外，應用程式可能也需要儲存您所撰寫的內容，讓您在離開並返回時不會遺失任何工作。

在這個範例中，系統在回應使用者輸入的字元時，需要執行下列四個動作。不過，您只須完成第一個項目，系統才會顯示下一個影格。

1. 根據使用者輸入的內容更新文字方塊，並套用任何必要格式。
2. 更新 UI 中顯示目前字數的部分。
3. 執行邏輯以檢查拼字錯誤。
4. 將最近的變更儲存在本機或遠端資料庫。

執行此動作的程式碼可能如下所示：

textBox.addEventListener('input', (inputEvent) => {
  // Update the UI immediately, so the changes the user made
  // are visible as soon as the next frame is presented.
  updateTextBox(inputEvent);

  // Use `setTimeout` to defer all other work until at least the next
  // frame by queuing a task in a `requestAnimationFrame()` callback.
  requestAnimationFrame(() => {
    setTimeout(() => {
      const text = textBox.textContent;
      updateWordCount(text);
      checkSpelling(text);
      saveChanges(text);
    }, 0);
  });
});

下圖顯示將任何非關鍵更新延遲到下一個影格之後，可如何縮短處理時間長度，進而減少整體互動延遲時間。

雖然在上述程式碼範例的 requestAnimationFrame() 呼叫中使用 setTimeout() 不可否認，但這個有效方法適用於所有瀏覽器，可確保非關鍵的程式碼不會封鎖下一個影格。

避免版面配置輾轉現象

版面配置輾轉現象 (有時稱為強制同步版面配置) 是一種轉譯效能問題，表示版面配置會同步發生。當您在 JavaScript 中更新樣式，然後在相同工作中讀取這些樣式時，就會發生這種狀況。JavaScript 中的許多屬性可能會造成版面配置輾轉現象。

版面配置輾轉造成效能瓶頸，因為只要更新樣式，然後立即透過 JavaScript 要求這些樣式的值，瀏覽器就會被迫執行同步版面配置工作，否則在事件回呼執行完成後，可能必須等到事件回呼執行之後，才能以非同步方式執行。

盡可能縮短簡報延遲時間

互動的「顯示延遲時間」標示是從互動的事件回呼執行完畢之後，直到瀏覽器可以繪製下一個影格，顯示產生的視覺變更。

盡量減少 DOM 大小

當網頁的 DOM 較小時，轉譯工作通常很快就會完成。但是，當 DOM 大型語言模型時，轉譯工作通常會隨著 DOM 大小增加而擴充。轉譯工作和 DOM 大小之間的關係不是線性，但大型 DOM 需要轉譯的工作量會比小型 DOM 還要多。大型 DOM 會在以下兩種情況發生問題：

1. 初始頁面轉譯期間，大型 DOM 需要執行大量工作才能轉譯頁面的初始狀態。
2. 回應使用者互動時，大型 DOM 可能會導致算繪更新耗費高昂成本，因而增加瀏覽器顯示下一個影格所需的時間。

請記住，在某些情況下，大型 DOM 無法大幅減少。雖然您可以採用一些方法來縮減 DOM 大小，例如縮減 DOM 或在使用者互動期間加進 DOM，以縮減初始 DOM 大小，但這些技術可能還無法達成目標。

使用 content-visibility 延後轉譯螢幕外元素

如要限制因使用者互動而在網頁載入和轉譯作業期間轉譯工作量，其中一種方法是充分利用 CSS content-visibility 屬性，讓元素能在元素接近可視區域時延遲顯示元素。雖然 content-visibility 可有效發揮效用，但還是值得調查一下，如果轉譯時間較短，就能改善網頁的 INP 功能。

使用 JavaScript 轉譯 HTML 時，請注意效能成本

不論是 HTML 或 HTML 都可以剖析，瀏覽器完成將 HTML 剖析為 DOM 後，瀏覽器還是必須對 HTML 套用樣式、計算版面配置，然後轉譯該版面配置。此為可避免的費用，但與轉譯 HTML 相關的「方法」至關重要。

伺服器傳送 HTML 時，會以串流形式傳送至瀏覽器。「串流」是指伺服器的 HTML 回應以區塊的形式抵達。瀏覽器會在串流收到串流時逐步剖析區塊，並位元轉譯，藉此最佳化處理串流的方式。這是因為瀏覽器會在網頁載入期間定期自動提供成效最佳化，而且完全免費。

雖然初次造訪任何網站時，一定會牽涉到「一些」 HTML 程式碼，但常見的做法是先從最少的 HTML 程式碼開始，然後使用 JavaScript 來填入內容區域。後續更新內容區域也會因為使用者互動而產生。這通常稱為單頁應用程式 (SPA) 模式。這個模式的缺點之一是，在用戶端使用 JavaScript 轉譯 HTML 後，您不僅可以獲得建立該 HTML 的 JavaScript 處理費用，還能在剖析該 HTML 並完成轉譯之前，瀏覽器不會產生收益。

但請記住，即使是「非」 SPA 的網站，在互動後，可能也需要透過 JavaScript 進行一些 HTML 轉譯。這通常沒問題，前提是您的用戶端不會轉譯大量 HTML，導致下一個影格的顯示時間延遲。不過，請務必瞭解這種方法在瀏覽器中呈現 HTML 會對效能造成哪些影響，以及如果您透過 JavaScript 轉譯大量 HTML，這對網站回應速度的影響，會如何影響使用者輸入的網站回應速度。

結論

改善網站的 INP 是一項反覆改進的程序，修正欄位中的互動速度緩慢問題後，很可能就會發現其他緩慢的互動 (特別是網站提供許多互動性時)，您也需要順便找出其他緩慢的互動，這時再著手改善。

改善 INP 的關鍵在於持續性。把握時機，確保網頁回應速度良好，讓使用者獲得滿意的體驗。為使用者開發新功能時，您可能也需要完成相同的程序，才能進一步為使用者打造最佳互動體驗。雖然要花時間和心力，但值得花時間和精力。

主頁橫幅由 David Pisnoy 提供，由 David Pisnoy 提供，並依據無啟動設施授權修改。