INP 優化終極指南：拆解三大樽頸，提升網頁反應速度

INP 係咩？拆解三個組成部分

Google 嘅 Interaction to Next Paint（INP） 係用嚟評估網頁對用戶操作嘅反應速度。根據 Chrome 開發者文檔，每一次互動都可以拆成三個階段 ：

1. 輸入延遲（input delay）：「由用戶開始互動嗰刻開始，到瀏覽器開始執行相關 event callback 為止。」
2. 處理時間（processing duration）：「係指 event callback 由頭到尾執行晒所需要嘅時間。」
3. 渲染延遲（presentation delay）：瀏覽器執行完 callback 之後，渲染出下一格畫面嘅時間。官方文件指出互動包含呢三個部分 ，但未有提供完整嘅定義原文。

好嘅 INP 係幾多？

• 低於 200 毫秒：反應良好
• 200 至 500 毫秒：需要改善
• 超過 500 毫秒：反應太慢，用戶會覺得「㩒極都冇反應」

---

點樣對症下藥？按三個部分分別優化

Chrome 文檔強調，想 INP 達標，「你要令互動嘅每個部分都盡可能地短」，唔可以剩係搞 input delay。

🔍 高輸入延遲（High Input Delay）

如果 INP 嘅瓶頸喺呢度，表示「個互動可能唔係慢嘅直接原因，而係俾主線程其他工作 delay 咗」。你要檢查有冇其他長任務（long task）霸住條 thread，令到 event callback 冇得準時開波 。

點搞？ 減少主線程嘅不必要工作，例如喺 idle time 先做非關鍵任務，或者用 setTimeout ／ requestIdleCallback 嚟延遲非必要嘅 JS 執行。

🔍 高處理時間（High Processing Duration）

呢個就係「互動嘅 event handler 直接搞慢咗 INP」。你要 audit 所有 event listener，因為「任何喺任何 event listener 入面 run 嘅 code，都會拖慢個互動」，包括自己寫嘅、框架嘅、library 嘅同第三方嘅 script。

點搞？

• 減少 event handler 入面嘅工作量，例如用防抖（debounce）或節流（throttle）
• 避免喺 handler 入面做大量 DOM 操作或複雜計算
• 考慮用 setInterval 代替連續快速觸發嘅 handler

🔍 高渲染延遲（High Presentation Delay）

呢個係瀏覽器畫出結果嘅階段慢咗。Chrome 文檔建議調查瀏覽器喺 callback 之後嘅渲染工作 ，但官方文件入面嘅完整建議被截斷咗，冇提供原文。一般做法係優化 CSS 樣式計算、減少重排（reflow）同重繪（repaint）。

---

總結：三個階段一齊睇，唔好淨係改 input delay

好多人以為 INP 慢就係「㩒掣嗰吓 delay」，但其實可能係背後嘅 event handler 太長氣，或者瀏覽器渲染太慢。Chrome 官方建議你用 DevTools 嘅 INP breakdown 功能，記錄多啲唔同嘅互動，睇清邊個階段最耐，然後集中火力優化最慢嗰 part 。

</br> --- *本文係基於 Chrome 開發者文檔[1]同 web.dev 官方指南整理而成，所有引用已標註來源編號。*