INP（互動到下一次繪製）是核心網頁指標之一，用來衡量「使用者在你的網頁上點按、輸入之後，畫面要多久才會給出反應」。簡單說，它量的就是一個網頁「反應靈不靈敏、會不會卡」。
這篇文章會用新手角度說明：INP 是什麼、200 毫秒的良好門檻怎麼來、一次互動的延遲是由哪三段組成、它和被取代的 FID 差在哪，以及實際上要怎麼檢查與改善。
重點速覽
- INP 是核心網頁指標之一，量的是使用者點擊、輸入之後畫面的反應速度，良好門檻是 200 毫秒以內。
- 一次互動延遲由輸入延遲、處理時間、呈現延遲三段組成，最大元凶是主執行緒上跑超過 50 毫秒的「長工作」。
- INP 在 2024 年 3 月 12 日正式取代舊的 FID，衡量範圍從「只看第一次互動」擴大到「整頁所有互動」。
INP 是什麼？
依 web.dev（Google 的開發者資源）的定義，INP 會觀察使用者在整個造訪期間「所有的互動」——點擊、觸控、按鍵——的反應延遲，再回報一個數值，代表幾乎所有互動都在這個時間之內完成。
和量「載入速度」的 LCP、量「視覺穩定度」的 CLS 不同，INP 量的是第三件事：互動的「反應速度」。
要記住一件事：INP 的單位是毫秒（ms），數字越小越好，代表你點下去之後畫面越快回應。
它取的接近你整頁體驗裡「最慢的那幾次互動」，所以只要有幾個按鈕特別卡，整頁的 INP 就會被拉高。
官方建議的門檻整理如下表：
| 評級 | INP 數值 | 代表意義 |
|---|---|---|
| 良好 | ≤ 200 毫秒 | 反應靈敏，幾乎不卡頓 |
| 待改善 | 200 – 500 毫秒 | 偶爾會感覺到延遲 |
| 不佳 | > 500 毫秒 | 常常一點就卡，體驗很差 |
和其他核心網頁指標一樣，Google 是用「真實使用者數據」的第 75 百分位數（p75）來判定，並把行動裝置與桌機分開看。
白話說，就是要有 75% 的造訪，INP 都在 200 毫秒以內，這一頁才算「良好」。
用白話文怎麼說？
你可以把網頁想成一個店員。你問他一句話（按一個按鈕），他要多久才抬頭回應你？
如果幾乎是秒回，你會覺得這家店很俐落；如果你每問一句，他都要愣個兩三秒才動，你就會開始煩躁，覺得這網站「很鈍」。
INP 量的，就是這個「從你出手到畫面有反應」的等待感。
更具體一點：你在手機上點「加入購物車」，結果按鈕按下去沒動靜，過了半秒畫面才更新——你甚至會懷疑自己是不是沒點到，忍不住又戳一次。
那種延遲，就是 INP 想抓出來的東西。
你可以這樣記：LCP 顧的是「畫面多快出現」，CLS 顧的是「出現之後穩不穩」，INP 顧的是「你動手之後它多快回應」。三個合起來，才是完整的好體驗。
INP 實際上要做什麼？
第一步，先拆解「一次互動的延遲是由哪三段組成的」，你才知道要救哪一段。web.dev 把每一次互動拆成三段：
- 輸入延遲（input delay）：從你按下去，到瀏覽器「開始」跑對應程式之間的等待。如果這時主執行緒正忙著別的工作，你的點擊就得排隊。
- 處理時間（processing duration）：事件處理程式（通常是 JavaScript）實際執行、算出該做什麼所花的時間。
- 呈現延遲（presentation delay）：程式跑完後，瀏覽器重新計算版面、把更新後的下一個畫面畫到螢幕上所花的時間。
這三段加起來，就是這一次互動的延遲；INP 取的，是你整頁裡數一數二長的那一次。
第二步，認識最大元凶：「長工作」。依 web.dev，任何在主執行緒上一口氣跑超過 50 毫秒的工作，就算一個「長工作（long task）」。
主執行緒一次只能做一件事，當它被一段長工作卡住，你此刻的點擊就只能乾等——這正是輸入延遲變長的主因。
第三步，對症下藥。常見且有效的改善方向包括：
- 把長工作切小：別讓一段 JavaScript 一口氣跑很久，把它切成多個小段，中間「讓出」主執行緒，瀏覽器才有空先回應使用者。
- 善用
scheduler.yield()：這是較新的排程 API，用來在長工作中間主動讓步；和傳統的setTimeout不同，它會保留原本的優先順序，讓你的程式在處理完使用者輸入後盡快接著跑。 - 事件處理程式裡少做事：使用者一點就要跑的程式，原則是「能少做就少做」，把不急的運算延後或搬走。
- 把粗重運算丟給 Web Worker：耗時的計算可以交給背景執行緒（Web Worker）去算，主執行緒只負責把結果畫出來，畫面就不會被卡住。
- 控制 DOM 與版面複雜度：頁面元素太多、太複雜，瀏覽器「畫下一張」就會變慢，呈現延遲跟著拉長。
第四步，照這個流程檢查：
- STEP 1 看真實數據：到 Google Search Console 的「核心網頁指標」報表，或 PageSpeed Insights 看田野數據裡的 INP。
- STEP 2 現場重現：用 Chrome 開發者工具的 Performance 面板，或
web-vitals套件，邊操作邊看哪個互動最慢、卡在三段裡的哪一段。 - STEP 3 對症處理：依上面方向，先救最慢、又最常被點的那幾個互動。
- STEP 4 過幾週再回看：田野數據以 28 天滾動計算，別期待今天改、明天就變綠。
關於 INP 的常見迷思
迷思一：INP 和舊的 FID 是同一回事
不是。INP 在 2024 年 3 月 12 日正式取代 FID，成為核心網頁指標。
兩者差很多：FID 只量「第一次互動」、而且只量三段裡的「輸入延遲」那一段；INP 量的是「所有互動」、而且涵蓋輸入延遲、處理時間、呈現延遲完整三段。
所以 INP 嚴格得多——很多在 FID 時代看起來很順的網站，換到 INP 就現出原形。
迷思二：只要把第一次點擊弄快就好
不對，那是 FID 的舊思維。INP 看的是你整頁體驗裡偏慢的那幾次互動，不是只看開場第一下。
所以就算首次互動很快，只要中後段有某個按鈕、某個展開動作特別卡，INP 一樣會被拉高。
迷思三：INP 高，就是因為我的網路太慢
多半不是。INP 衡量的是「裝置上的反應速度」，主要卡在 JavaScript 佔住主執行緒、運算太重，跟你的下載頻寬是兩回事。
網路慢通常先反映在 LCP（載入），而不是 INP（反應）。
迷思四：分數沒到綠色，Google 就會把我大降排名
沒這麼直接。核心網頁指標是排名的考量之一，但只是「眾多訊號裡的一個」，通常在內容相近、難分高下時才比較看得出差別。
INP 該顧，但它是體驗的基本功，不是排名的開關。
總結
如果只記一句話：INP 量的是「你在網頁上點下去之後，畫面多快給你反應」，單位是毫秒，良好門檻是 200 毫秒以內（p75）。
新手可以記住三件事。
- 第一，先到 Google Search Console 看自己的 INP 落在哪一級，再用開發者工具找出最卡的那幾個互動。
- 第二，判斷延遲是卡在輸入延遲、處理時間還是呈現延遲，再從「把長工作切小、事件處理程式裡少做事」開始改。
- 第三，記得 INP 已在 2024 年 3 月 12 日取代 FID，衡量的是整頁所有互動，不是只看開場第一次點擊。
