如何改善與下一次繪製的交互 (INP)
已發表: 2023-07-15與 Next Paint (INP) 的交互不再是實驗性的。
自 2024 年 3 月起，Google 致力於將 INP 推廣為新的響應能力核心 Web 重要指標，取代首次輸入延遲。
雖然您可能認為處理網站的 INP 分數是一項可以推遲的任務，但我們不敢苟同。
Google 已經開始在 Search Console 中標記 INP 問題，並向未達到良好響應閾值的網站發送電子郵件：
換句話說，現在是開始針對即將到來的響應指標優化網站的最佳時機。 在接下來的幾行中，您將確切地了解如何操作。
- 與 Next Paint 的交互概述
- 了解交互延遲
- 為什麼您的網站未通過 INP
- 如何識別緩慢的交互
- 如何優化INP
請繼續閱讀。
與下一個繪畫的交互：概述
在深入研究各種優化技術之前，先快速回顧一下 INP 的測量內容。
INP 通過觀察用戶訪問頁面期間所有合格交互的延遲來評估頁面對用戶交互的整體響應能力。 最終的 INP 值是觀察到的最長相互作用。
在 INP 計算中起作用的相互作用是：
- 用鼠標點擊；
- 點擊帶有觸摸屏的設備；
- 按物理或數字鍵盤上的鍵。
與其他 Core Web Vitals 類似，您的 INP 分數可以處於以下三個閾值之一：
- 良好：0-200ms
- 需要改進：200-500ms
- 差：>500ms
為了確保您為大多數用戶實現這一目標，建議評估頁面加載的第 75 個百分位，跨移動和桌面設備進行細分。
如果您想了解更多信息或溫習有關 INP 的知識，請閱讀我們關於即將推出的響應度指標的文章。
了解交互延遲
如果您希望 INP 分數從差到好，您需要了解交互延遲。
那麼交互延遲到底是什麼？
交互延遲是指用戶的輸入或操作與屏幕上的響應或輸出之間所經歷的延遲或滯後。 它是決定網站響應能力和感知性能的關鍵因素。
三個主要因素會導致交互延遲：
輸入延遲
輸入延遲是指用戶開始與頁面交互和相關操作或事件回調開始執行之間的時間。 它包括由輸入設備（例如鍵盤、鼠標、觸摸屏）和系統的輸入處理機制引起的物理或技術延遲。
處理時間
收到用戶輸入後，系統必須對其進行處理以確定適當的響應或操作。 處理時間是指系統分析和解釋輸入數據、執行任何必要的計算或操作以及生成輸出或響應所需的持續時間。
演示延遲
系統生成輸出或響應後，在將其呈現給用戶之前通常會有一段延遲。 呈現延遲包括系統更新顯示、渲染圖形或用戶界面以及將輸出傳送到用戶界面或輸出設備所需的時間。
如果您需要更多信息，可以查看 Jeremy Wagner 在 JSConf Korea 2022 上的演講：
了解和優化交互延遲可以提供無縫的用戶體驗並修復您的 INP 分數。
但在此之前，我們先來看看造成高交互延遲和糟糕的 INP 分數的罪魁禍首……
在您的網站上檢測到 Core Web Vitals INP 問題：可能是什麼原因造成的？
儘管 INP 被標記為待處理，但這並不意味著您應該在沒有策略的情況下進入優化過程。
您需要做的第一件事是了解 INP 的主要罪魁禍首是什麼，以便您可以有效地處理它們。
以下是“INP問題：超過200ms”錯誤消息的主要原因：
長任務
瀏覽器所做的一切都被視為一項任務。 這包括渲染、解析 HTML、運行 JavaScript 以及您可能控製或無法控制的任何內容。
主線程是瀏覽器完成顯示頁面所需的大部分工作的地方。 雖然可能有幾十個任務需要執行，但主線程一次只能處理一個任務。
但這只是問題的一半。
另一半是，如果任務執行時間超過 50 毫秒，則將其歸類為長任務。
考慮到主線程一次只能處理一個任務，任務越長，瀏覽器在處理它時被阻塞的時間就越長。
換句話說，如果用戶在長時間任務運行時嘗試與頁面交互，瀏覽器將延遲滿足請求。
結果是交互延遲和較低的 INP 分數。
大 DOM 大小
INP 失敗的另一個原因是 DOM 尺寸過大。
文檔對像模型 (DOM) 是每個網頁不可分割的一部分。 DOM 是結構為樹的 HTML 文檔的表示。 樹中的每個分支都終止於一個節點，每個節點都包含對象。 節點可以表示文檔的不同部分，例如元素、文本字符串或註釋。
DOM 本身不是問題，但它的大小可能是問題。 較大的 DOM 大小會影響瀏覽器快速有效地呈現頁面的能力。
DOM 越大，最初顯示頁面以及在頁面生命週期中進行後續更新所需的資源就越多。
簡單的說：
如果您希望頁面快速響應用戶交互，請確保您的 DOM 僅包含必要的元素。
您可能想知道“必要”是什麼意思。 根據 Lighthouse 的說法，當頁面的 DOM 大小超過 1,400 個節點時，就屬於過大。
因此，請確保保持在這個限制之內。 否則，您可能會在 PageSpeed Insights 報告中看到以下錯誤：
HTML 的客戶端呈現
要理解為什麼客戶端渲染可能會導致 INP 分數較低，我們需要解釋它與 HTML 的服務器端渲染有何不同。
傳統的頁面加載涉及瀏覽器在每次導航時從服務器接收 HTML。 當一個人決定加載頁面時，後台會發生什麼：
- 瀏覽器發送針對所提供的 URL 的導航請求。
- 服務器以塊的形式響應 HTML。
這裡的關鍵是“分塊”。
當瀏覽器收到第一個 HTML 塊時，它就可以開始解析它。 但眾所周知，解析 HTML 是主線程處理的任務。
但是，處理完每個塊後，瀏覽器會暫停解析並允許執行其他任務。 這可以防止可能降低瀏覽器速度的長任務。
相反，它可以開始渲染頁面中已解析的部分，以便用戶更快地看到部分加載的頁面。 它還可以處理頁面初始加載期間發生的任何用戶交互。
換句話說：
這種方法可以使頁面獲得更好的下次繪製交互 (INP) 分數。
相反，如果您的網站使用單頁應用程序 (SPA) 模式（該模式使用 JavaScript 在客戶端上動態創建大部分 HTML/DOM），那麼您的 INP 分數可能會受到負面影響。
在客戶端渲染中，服務器將一小塊基本 HTML 發送到客戶端。 然後，客戶端負責使用從服務器獲取的數據填充頁面的主要內容。
所有未來的導航都由 JavaScript 處理，從服務器獲取新的 HTML 並動態更新頁面，而無需完全重新加載。 不幸的是，當涉及到客戶端的 JavaScript 任務時，它們不會自動分塊。
這可能會導致長時間的任務阻塞主線程，從而可能影響頁面的“與下一個繪製的交互”分數。 因此，客戶端渲染可能會損害頁面的加載和交互性。
如果您需要有關服務器端渲染與客戶端渲染的優缺點的更多信息，請觀看此視頻：
現在您已經了解了一些主要的罪魁禍首，讓我們繼續測量您的 INP 分數並識別緩慢的相互作用。
如何使用現場數據識別緩慢的交互並在實驗室中調試它們
INP 優化之旅的下一步是衡量網站的性能並識別任何緩慢的交互。
與首次輸入延遲類似，INP 最好在現場測量 - 檢查真實用戶如何體驗您的網站。
最佳的測試過程如下所示：
- 收集 INP 的現場數據
- 確定對 INP 負責的確切行動
- 使用實驗室工具找出這些交互緩慢的原因
我們說最佳是因為，在某些情況下，您的站點可能沒有現場數據（也稱為真實用戶監控 (RUM) 數據）。 然而，這並不意味著您應該放棄優化 INP 分數。 您需要採取不同的方法並利用可用的實驗室工具。
讓我們看一下這兩種情況，並解釋如何獲取大部分現場和實驗室數據。
現場數據
理想情況下，當您開始提高網站的響應能力時，您會希望擁有現場數據。 依靠 RUM 數據可以節省您大量時間來確定哪些交互需要優化。
此外，基於實驗室的工具可以模擬某些交互，但無法完全複製現實世界的用戶體驗。
收集 INP 現場數據時，您需要捕獲以下信息以提供交互緩慢原因的背景信息：
- INP 值 –這些值的分佈將確定頁面是否滿足 INP 閾值。
- 負責頁面 INP 的元素選擇器字符串 –僅僅知道頁面的 INP 值是不夠的。 您想知道哪些元素負責交互。
- 頁面交互的加載狀態（即頁面的 INP）——了解交互是否發生在頁面加載期間或之後，有助於確定是否應該優化主線程或交互本身是否緩慢，無論頁面的初始加載如何。
- 交互的開始時間 –確保記錄交互的開始時間，因為它可以讓您知道交互何時在性能時間線上發生。
- 事件類型 –了解交互事件類型 – 單擊按鍵、其他符合條件的事件 – 允許您查明交互中哪個事件回調運行時間最長。
如果你問自己：
我該如何捕捉所有這些東西？
不用擔心。 所有數據都在 web-vitals JavaScript 庫中公開。 您可以查看 Google 的分步指南，了解如何利用 web-vital 庫，甚至如何將 INP 數據直接傳輸到您的 Google Analytics。
此外，即使您已經通過第三方 RUM 提供商收集數據，也請考慮將其與 Chrome 用戶體驗報告 (CrUX) 數據進行比較，因為它們使用的方法存在差異。
實驗室數據
現場數據是最可靠的測量來源。 然而，正如我們所說，它並不總是可用。
但無需擔心，因為您仍然可以藉助實驗室數據來測量和識別交互以進行改進。
您可以使用 Lighthouse 或 PageSpeed Insights 來運行一些性能測試。 您應該關注的指標是總阻塞時間（TBT）。
TBT 是一種評估加載期間頁面響應能力的指標，與 INP 密切相關。 TBT 分數較差表明頁面加載期間交互可能很慢。
以下是如何重現與實驗室工具的緩慢交互：
- 使用 Web Vitals Chrome 擴展程序
Web Vitals Chrome 擴展程序是測量網站交互延遲的最簡單方法之一。 您需要執行以下操作來檢索有用信息：
- 在 Chrome 中，單擊地址欄右側的擴展程序圖標。
- 在下拉菜單中找到 Web Vitals 擴展。
- 單擊右側的圖標打開擴展程序的設置。
- 單擊選項。
- 在出現的屏幕中啟用控制台日誌記錄複選框，然後單擊保存。
最後，打開 Chrome DevTools 控制台並開始測試。 您將收到有用的控制台日誌，為您提供交互的詳細診斷信息。
- 使用 Chrome DevTools 記錄跟踪
要獲取有關交互緩慢原因的更多信息，您可以使用 Chrome DevTools 中的性能分析器。 只需執行以下操作：
- 打開 Chrome DevTools 並轉到“性能”面板。
- 單擊面板左上角的“記錄”按鈕開始跟踪。
- 執行所需的交互。
- 再次單擊“記錄”按鈕可停止跟踪。
要快速識別性能問題，請在填充配置文件時檢查分析器頂部的活動摘要。 在活動摘要中查找紅色條，指示記錄期間的長任務實例。 這些紅色條可幫助您查明問題區域並集中調查。
- 使用燈塔時間跨度
Lighthouse 的時間跨度模式是 DevTools 性能分析器的更簡單的替代方案。 使用方法如下：
- 轉到 DevTools 中的 Lighthouse 選項卡。
- 在標記為“模式”的部分下，選擇“時間跨度”選項。
- 在標記為“設備”的部分下選擇所需的設備類型。
- 確保至少選中“類別”標籤下標有“性能”的複選框。
- 單擊開始時間跨度按鈕。
- 測試頁面上所需的交互。
- 單擊結束時間跨度按鈕並等待審核出現
- 審核填充後，按 INP 對其進行過濾。
您將看到失敗和通過審核的列表。 當您單擊它們時，將出現一個下拉菜單，您可以看到交互期間花費的時間除以輸入延遲、處理時間和呈現延遲的細分。
來源：谷歌
現在您知道要做什麼，是時候捲起袖子開始優化了。
如何優化INP
為了保證您的網站獲得良好的INP 分數，您需要確保每個交互事件盡可能快地運行。 以下是如何實現它：
減少輸入延遲
1. 避免重複計時器導致主線程超負荷
setTimeout 和 setInterval 是常用的 JavaScript 計時器函數，可能會導致輸入延遲。
setTimeout安排回調在指定時間後運行，雖然它可以幫助避免長時間的任務，但它取決於超時發生的時間以及是否與用戶交互一致。
另一方面， setInterval安排回調以指定的時間間隔重複運行。 因此，它更有可能干擾用戶交互。 它的重複性會增加輸入延遲，並可能影響交互的響應能力。
如果您可以控制代碼中的計時器，請評估它們的必要性並儘可能減少它們的工作量。
2.避免長時間的任務
如您所知，長任務會阻塞主線程，從而阻止瀏覽器執行交互事件。
為了增強站點的響應能力，最小化主線程上的工作負載並考慮分解長任務非常重要。
通過將長任務分解為較小的塊，主線程有機會處理其他任務並更快地響應用戶交互。
此外，分解長任務有助於避免“卡頓”效應，即頁面上的動畫和過渡由於主線程不堪重負而變得斷斷續續或斷斷續續。 通過確保每個任務在更短的時間內完成，頁面可以為用戶保持更流暢的視覺體驗。
3.避免交互重疊
交互重疊意味著訪問者與一個元素交互後，他們在初始交互有機會渲染下一幀之前與頁面進行另一次交互。
例如，當用戶在表單字段中鍵入內容時可能會發生這種情況，從而導致在短時間內進行大量鍵盤交互。 您可以通過以下方式優化流程：
- 對輸入進行去抖動以限制事件回調在給定時間段內執行的次數。
- 使用 AbortController 取消傳出的獲取請求，這樣主線程就不會在處理獲取回調時過度勞累。
優化事件回調（處理時間）
1.考慮刪除不必要的回調
昂貴的事件回調真的有必要嗎？ 如果沒有，請考慮完全刪除代碼，或者如果不可能，則將其執行延遲到更合適的時間。
把它想像成一個連鎖反應。 當您在網站上執行操作（例如單擊按鈕）時，網站會將該操作識別為事件。 然後，網站會查找與該事件相關的特定代碼段（稱為回調函數）。 一旦找到回調函數，它就會被執行，並決定接下來應該發生什麼。
2.推遲非渲染工作
長任務可以通過屈服於主線程來分解。 當您屈服於主線程時，您實際上暫停了當前任務並將剩餘的工作拆分為一個單獨的任務。 這允許渲染器處理先前在事件回調中處理的用戶界面的更新。 通過讓步，您可以使渲染器執行掛起的更改並確保平滑且及時的用戶界面更新。
讓出主線程是指暫時暫停主線程上運行的任務的執行，以允許處理其他任務。 當主線程上的任務讓出時，意味著它自願放棄控制權並允許執行其他掛起的任務。 這種機制可以防止長時間運行的任務獨占主線程並導致用戶界面無響應。
最大限度地減少演示延遲
1. 減小 DOM 大小
較大的 DOM 肯定會導致 INP 評估失敗。 因此，為了確保這種情況不會發生，您需要減小 DOM 大小，或者換句話說，您需要減小 DOM 深度。
目標是 DOM 深度不超過 1,400 個節點。
您可以通過結合以下技術來實現它：
- 避免編碼不良的插件和主題
- 最小化基於 JavaScript 的 DOM 節點
- 遠離生成臃腫 HTML 的頁面構建器
- 不要將文本複制/粘貼到所見即所得編輯器中
- 將您的一頁網站分解為多個頁面
- 不要使用 display:none 隱藏不需要的元素
- 避免使用複雜的 CSS 聲明和 JavaScript
2. 避免在 requestAnimationFrame 回調中進行過多或不必要的工作
requestAnimationFrame方法告訴瀏覽器您希望執行動畫，並請求瀏覽器在下一次重繪之前調用指定的函數來更新動畫。
requestAnimationFrame() 回調是事件循環中渲染階段的一部分，需要在顯示下一幀之前完成。 如果您使用 requestAnimationFrame() 來執行與用戶界面更改無關的任務，則必須認識到您可能會導致後續幀的渲染延遲。
因此，在不必要的時候避免使用它們。
3.延遲ResizeObserver回調
ResizeObserver 接口報告元素內容或邊框框或 SVGElement 邊框的尺寸變化。
ResizeObserver 回調在渲染之前運行，如果涉及資源密集型任務，則可能會推遲下一幀的呈現。 與事件回調類似，建議推遲立即即將到來的幀不需要的任何不必要的邏輯。
使用 NitroPack 改善 INP
根據我們過去幾個月運行的所有測試以及 Google 在 INP 上發布的所有文檔，我們可以說它與 Largest Contentful Paint (LCP) 非常相似。
具有許多活動部件的多層 Core Web Vital。
因此，自從 Google 首次宣布新的響應度指標以來，我們就開始測試和開發可提高客戶 INP 分數的功能。
我們已經看到了一些有希望的結果：
借助 NitroPack，我們的客戶的 INP 平均提高了 36%。
而這一切都是自動發生的。 只需安裝 NitroPack 並藉助以下優化功能即可：
- 減少未使用的 CSS
- 延遲 JavaScript 加載
- 內置CDN
您還可以提高 INP 和 Core Web Vitals 分數，而無需編寫任何代碼。 免費安裝 NitroPack 並親自體驗改進。