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

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

Jeremy Wagner
Philip Walton

Interaction to Next Paint (INP) 是穩定的 Core Web Vitals 指標，可評估網頁回應使用者互動的整體效能，方法是觀察使用者造訪網頁期間，網頁對所有符合資格的互動的延遲時間。最終 INP 值是觀察到的最長互動 (有時忽略離群值)。

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

良好的 INP 值為 200 毫秒以下，不良的值則為 500 毫秒以上，介於兩者之間的值則需要改善。

視網站而定，互動可能很少，甚至完全沒有，例如網頁主要由文字和圖片組成，互動元素很少或完全沒有。而對於文字編輯器或遊戲等網站，則可能帶來數十甚至數千次的互動。無論是哪種情況，如果 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，這些工作包括剖析指令碼以確保其語法有效、將其編譯為 bytecode，然後執行。

視指令碼大小而定，這項工作可能會在主執行緒上引入長時間的工作，導致瀏覽器延遲回應其他使用者互動。為了讓網頁在載入期間能回應使用者輸入內容，請務必瞭解如何減少在載入期間執行長時間任務的可能性，讓網頁保持快速回應。

最佳化事件回呼

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

經常產生給主執行緒

在最佳化事件回呼時，最佳的一般建議是盡量減少回呼中的工作量。不過，您的互動邏輯可能相當複雜，而且您能夠縮減其工作量。

如果發現您的網站也是這種情況，下一個可嘗試的方法是將事件回呼中的作業拆解為個別工作。這樣可以避免集體工作成為會封鎖主執行緒的長時間工作，讓原本在主執行緒上等待的其他互動更快執行。

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

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

用來加快算繪工作的速度

更進階的讓步技巧包括在事件回呼中建構程式碼，以便限制執行的內容，只限於為下一個影格套用視覺更新所需的邏輯。其他所有內容都可以延後至後續工作。這不僅可讓回呼輕巧靈活，還可改善互動顯示時間，因為系統不會允許視覺更新阻斷事件回呼程式碼。

舉例來說，假設有個富文字編輯器，會在您輸入內容時設定文字格式，並根據您輸入的內容更新 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 中的許多屬性可能會造成版面配置輾轉現象。

在 Chrome 開發人員工具的效能面板中視覺化呈現版面配置輾轉現象。
如 Chrome 開發人員工具的效能面板所示，這是版面配置衝突的範例。涉及版面配置耗損的轉譯工作，會在呼叫堆疊部分的右上角顯示紅色三角形，通常會標示為「Recalculate Style」或「Layout」。

版面配置衝突是效能瓶頸，因為更新樣式後，系統會立即在 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 開始，然後使用 JavaScript 填入內容區域。後續更新內容區域也會因為使用者互動而產生。這通常稱為單頁應用程式 (SPA) 模型。此模式的一個缺點是，如果您在用戶端上使用 JavaScript 算繪 HTML，不僅要付出 JavaScript 處理作業的成本來建立 HTML，瀏覽器也必須先完成剖析 HTML 並算繪，才能不產生。

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

結論

改善網站的 INP 是一項疊代程序。修正互動速度緩慢的問題後，您很可能會發現其他互動速度緩慢的問題，尤其是如果您的網站提供大量互動功能，就更有可能發生這種情況。因此，您也需要對這些互動進行最佳化。

改善 INP 的關鍵在於持之以恆。隨著時間過去，您可以讓網頁的回應速度達到使用者滿意的程度。當您為使用者開發新功能時，也可能需要進行相同的程序，針對他們的互動進行最佳化。這項作業需要花費時間和心力，但絕對值得。

主頁橫幅圖片取自 Unsplash，由 David Pisnoy 拍攝，並根據 Unsplash 授權進行修改。