瞭解如何最佳化網站與下一個顯示畫面的互動方式。
「與下一個顯示內容的互動 (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 提供的功能。
在研究室中診斷緩慢的互動情形
理想情況下,一旦有可表明互動緩慢情形的實際資料,建議您先在研究室中進行測試。在缺少現場資料的情況下,可以運用一些策略,識別研究室中緩慢的互動。這類策略包括追蹤常見的使用者流程,並在過程中測試各種互動情形,以及在載入期間與網頁互動 (主要執行緒通常最忙碌的時候),以便找出使用者體驗中關鍵部分的緩慢互動。
提升互動成效
發現緩慢的互動情形,且在研究室中手動重現後,下一步就是最佳化。互動可分為三個階段:
- 輸入延遲,是從使用者與網頁互動時開始,並在互動事件回呼開始執行時結束。
- 「處理時間長度」,包含事件回呼所需的執行時間。
- 顯示延遲,這是瀏覽器顯示下一個影格所需的時間,內含互動的視覺結果。
這三個階段的總和是總互動延遲時間。每個互動階段都會產生一段總互動延遲的時間,因此請務必瞭解如何最佳化各個互動環節,盡可能讓互動過程盡可能縮短。
識別並縮短輸入延遲時間
使用者與網頁互動時,互動的第一部分是「輸入延遲」。視網頁上的其他活動而定,輸入的延遲時間可能較長。這可能是因為活動發生在主執行緒上 (可能是指令碼載入、剖析和編譯)、擷取處理、計時器函式,甚至是快速連續且彼此重疊的其他互動造成。
無論互動的輸入延遲時間為何,您都希望將輸入延遲時間降到最低,讓互動可以盡快開始執行事件回呼。
啟動期間指令碼評估與長時間工作之間的關係
在啟動期間,頁面生命週期中互動的一大關鍵。系統載入網頁時,一開始會先顯示,但請注意,即使頁面「已轉譯」,也不代表該網頁已經完成載入,視網頁需要完全正常運作的資源而定,使用者在網頁載入期間可能會嘗試與網頁互動。
網頁載入時,可能會延長互動的輸入延遲時間,就是指令碼評估。從網路擷取 JavaScript 檔案後,瀏覽器會繼續執行 JavaScript,以便執行 JavaScript;這個作業包含剖析指令碼以確保其語法有效,將指令碼編譯為位元碼,最後執行指令碼。
視指令碼的大小而定,這項工作可能會在主執行緒上產生很長的工作,導致瀏覽器無法回應其他使用者的互動。為了讓網頁在載入網頁時能回應使用者輸入的內容,務必瞭解如何減少網頁載入期間長時間完成工作的可能性,讓網頁保持簡單明瞭。
最佳化事件回呼
輸入延遲時間只是 INP 評估的第一部分。此外,您也必須確認為了回應使用者互動而執行的事件回呼能夠盡快完成。
經常產生給主執行緒
最佳化事件回呼的最佳通用建議是盡可能避免執行。不過,您的互動邏輯可能相當複雜,而且您能夠縮減其工作量。
如果發現網站有這種情況,接下來可嘗試將事件回呼中的工作拆分為不同的工作。這樣可以避免集體工作成為會封鎖主執行緒的長時間工作,讓原本在主執行緒上等待的其他互動更快執行。
setTimeout
是分割任務的一種方式,因為傳遞至它的回呼會在新工作中執行。您可以單獨使用 setTimeout
,或將其用途提取至獨立函式,產生更符合人體工學的。
隨機產生比完全不產生收益更好,但產生到主要執行緒的細微差異是更加精細的,而且只有在更新使用者介面的事件回呼後,才會立即產生,讓算繪邏輯能更快執行。
用來加快算繪工作的速度
更進階的產生技術涉及在事件回呼中建構程式碼,限制要執行什麼動作,只能執行為下一個影格套用視覺更新所需的邏輯。其他郵件都可以延後到後續的工作。這樣不但能讓回呼變得輕快且靈活,而且不允許視覺化更新來封鎖事件回呼程式碼,從而改善互動的轉譯時間。
舉例來說,假設有一個 RTF 格式編輯器,會在輸入內容時設定文字格式,但也會根據你輸入的內容更新 UI 的其他部分 (例如字詞計數、醒目顯示拼字錯誤和其他重要的視覺回饋)。此外,應用程式可能也需要儲存您所撰寫的內容,讓您在離開並返回時不會遺失任何工作。
在這個範例中,系統在回應使用者輸入的字元時,需要執行下列四個動作。不過,您只須完成第一個項目,系統才會顯示下一個影格。
- 根據使用者輸入的內容更新文字方塊,並套用任何必要格式。
- 更新 UI 中顯示目前字數的部分。
- 執行邏輯以檢查拼字錯誤。
- 將最近的變更儲存在本機或遠端資料庫。
執行此動作的程式碼可能如下所示:
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);
});
});
下圖顯示將任何非關鍵更新延遲到下一個影格之後,可如何縮短處理時間長度,進而減少整體互動延遲時間。
![兩種情境下鍵盤互動和後續工作的說明。在上圖中,轉譯重要工作和所有後續背景工作都會同步執行,直到顯示畫面的機會為止。在下圖中,重要轉譯工作會先執行,接著產生主執行緒,以更快呈現新的影格。之後就會執行背景任務。](https://web.developers.google.cn/static/articles/optimize-inp/image/interaction-latency.png?authuser=6&hl=zh-tw)
雖然在上述程式碼範例的 requestAnimationFrame()
呼叫中使用 setTimeout()
不可否認,但這個有效方法適用於所有瀏覽器,可確保非關鍵的程式碼不會封鎖下一個影格。
避免版面配置輾轉現象
版面配置輾轉現象 (有時稱為強制同步版面配置) 是一種轉譯效能問題,表示版面配置會同步發生。當您在 JavaScript 中更新樣式,然後在相同工作中讀取這些樣式時,就會發生這種狀況。JavaScript 中的許多屬性可能會造成版面配置輾轉現象。
![在 Chrome 開發人員工具的效能面板中視覺化呈現版面配置輾轉現象。](https://web.developers.google.cn/static/articles/optimize-inp/image/a-visualization-layout-t-cefcc10055727.png?authuser=6&hl=zh-tw)
版面配置輾轉造成效能瓶頸,因為只要更新樣式,然後立即透過 JavaScript 要求這些樣式的值,瀏覽器就會被迫執行同步版面配置工作,否則在事件回呼執行完成後,可能必須等到事件回呼執行之後,才能以非同步方式執行。
盡可能縮短簡報延遲時間
互動的「顯示延遲時間」標示是從互動的事件回呼執行完畢之後,直到瀏覽器可以繪製下一個影格,顯示產生的視覺變更。
盡量減少 DOM 大小
當網頁的 DOM 較小時,轉譯工作通常很快就會完成。但是,當 DOM 大型語言模型時,轉譯工作通常會隨著 DOM 大小增加而擴充。轉譯工作和 DOM 大小之間的關係不是線性,但大型 DOM 需要轉譯的工作量會比小型 DOM 還要多。大型 DOM 會在以下兩種情況發生問題:
- 初始頁面轉譯期間,大型 DOM 需要執行大量工作才能轉譯頁面的初始狀態。
- 回應使用者互動時,大型 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 提供,並依據無啟動設施授權修改。