INP、FID 介紹：Google 為何改用 INP 取代 FID？
把 INP 當成「FID 的嚴格版」是常見的誤解。它其實把衡量對象從第一次互動的單點延遲，整個換成使用期間最差一次互動的完整延遲，所以一個網站可以 FID 滿分、INP 卻不及格。…
把 INP 當成「FID 的嚴格版」是常見的誤解。它其實把衡量對象從第一次互動的單點延遲，整個換成使用期間最差一次互動的完整延遲，所以一個網站可以 FID 滿分、INP 卻不及格。Google 自 2024 年 3 月起以 INP（Interaction to Next Paint）正式取代 FID（First Input Delay）成為 Core Web Vitals 穩定指標，良好門檻為 200 毫秒以內、不良為超過 500 毫秒 [來源：web.dev〈Interaction to Next Paint (INP)〉〈https://web.dev/articles/inp〉〈2024〉]。換指標的真正原因，是 FID 量得到的東西太片面，會讓開局漂亮、中後期卡頓的網站拿到虛假的好分數。
重點先看：FID 只量第一次互動的 input delay 單點，INP 量的是整段使用期間每一次互動、input delay + processing + presentation delay 三段加總，再取最差一次當分數；良好門檻 ≤200ms、不良 >500ms [來源：web.dev〈Interaction to Next Paint (INP)〉〈https://web.dev/articles/inp〉〈2024〉]。
接下來的目標只有一個：講清楚 INP 與 FID 量的時間段、事件範圍為什麼完全不同，Google 換指標背後的設計意圖是什麼，以及你身為前端工程師、SEO 人員或網站站長到底要不要緊張。如果你已經聽過 Core Web Vitals 白話文介紹，這裡是把「互動」這一塊拆到最細。如果你連 Core Web Vitals 都還很陌生，建議先回頭看一篇 SEO 入門自學懶人包 把地基打好，再回來讀會更有感。
INP 與 FID 差在哪：一句話講清楚 Google 換指標的本質
FID 只量使用者「第一次」互動時、瀏覽器開始處理事件前的延遲；INP 則量整段使用期間「每一次」互動、從點擊到畫面實際更新完的完整時間，並取最差一次當分數。兩者量的事件範圍不同、量到的時間段也不同，這代表題目整個被換掉，談誰比較嚴格其實沒有意義。Google 在 Google 搜尋引擎運作原理 之外，對自家體驗指標也做了同樣務實的校正。要把這組體驗指標放進 Core Web Vitals 與 SEO 排名的關係 來看，會更清楚換指標背後的用意。
先把兩個名字的本質拆開。FID 全名 First Input Delay，翻成「首次輸入延遲」，它只盯著使用者與網頁的第一次互動，而且只看「使用者點下去」到「瀏覽器開始動手處理」這段空窗。INP 全名 Interaction to Next Paint，翻成「互動至下一次繪製」，它盯著整個頁面生命週期內的每一次互動，而且把 input delay、event processing、presentation delay 三段全部加進來，最後取最差的那一次當代表。
為什麼說這是「換題目」？因為就算你把 FID 這道題做到滿分，也不保證 INP 會過。這就像考試改了考科，你國文滿級分，數學還是會被當。光記門檻數字沒用，先搞懂兩者量的根本是不同一件事。
| 維度 | FID（已退役） | INP（現役） |
|---|---|---|
| 互動次數 | 只量第一次 | 量整段使用期間全部互動 |
| 計算時間段 | 只有 input delay | input delay + processing + presentation delay 三段加總 |
| 取分方式 | 單一點 | 取所有互動裡最差一次 |
| 良好門檻 | ≤100ms | ≤200ms |
| 是否為穩定指標 | 2024 年 3 月退役 | 2024 年 3 月正式上線 [來源：web.dev〈Interaction to Next Paint (INP)〉〈https://web.dev/articles/inp〉〈2024〉] |
把兩者放在一起看，你會發現門檻數字本身根本不是重點。INP 的良好門檻 200ms 比 FID 的 100ms 還寬鬆，但幾乎所有做過實測的團隊都會告訴你：INP 遠比 FID 難過。原因就在取分方式，取最差一次 vs 取第一次，差距是天壤之別。把 INP 當成「FID 嚴格版」的人，通常會在實測時栽跟頭。而一個網站要撐得起「全程順暢」這四個字，從 SEO 友善網站架構 的分層、到 四大類型連結解析 裡的連結權重流動，全都會回頭影響主執行緒在每次互動時要扛多少負擔。指標換了，整個網站的體質也得跟著對齊。
只量第一次的代價：FID 漏掉了一整片卡頓
FID 滿分不代表網站順暢，因為它只記錄使用者第一次互動的那一瞬間，只要開場快、後面再卡都不會被算進去，「開局漂亮、中後期卡頓」的網站因此拿到虛假的高分。這是 FID 設計上的結構性限制，算不上 bug。
實務上，使用者第一次互動通常發生在頁面剛載入、資源還沒全部用上時，主執行緒往往還算空，瀏覽器很快就能開始處理那一下點擊，FID 數字自然漂亮。但使用者真正會抱怨的卡頓，幾乎都發生在第一次點擊之後：滾動到一半畫面頓一下、表單輸入時每打一個字就停頓、連點加入購物車時第二下沒反應。這些後續互動的處理時間與畫面更新延遲，FID 一概看不到，偏偏那兩段才是使用者最有感的地方。
常見的陷阱是這樣的：某個電商首頁 FID 只有 12ms，Search Console 的 Search Console 報表綠燈亮得很開心，轉換率卻一直上不去。用 web-vitals 程式庫採現場資料才發現，使用者在商品列表點「加入購物車」時，INP 高達 680ms，原因是那個按鈕的事件處理函式裡同步跑了一段價格計算，又觸發了整個 DOM 重算。FID 完全沒抓到這件事，因為第一次互動發生在還沒滾到商品區的時候。這類「分數漂亮、錢在漏」的落差，正是 Google 認為 FID 與真實體感脫節的核心原因，也是 網頁速度優化方法 必須跟著升級的原因；想系統性拉起整站載入效能，一份完整的 網站速度優化全攻略 會比零散修補更有效率。
把這個盲區放回整個 SEO 地圖看，體驗指標從來不是孤立的技術分數。搜尋意圖與關鍵字佈局決定了流量怎麼來，E-E-A-T 負責在內容面留住人，互動順不順暢則決定他願不願意留下來消費；在 AI 時代的 SEO 趨勢裡，體驗指標的權重只會越調越高，內容再好，卡頓就等於把人往外推。
INP 分數是怎麼加總出來的
INP 把每一次互動的 input delay、event processing、presentation delay 三段時間加總，在整個頁面生命週期內記錄所有互動，最後取最差（最久）的一次當代表分數 [來源：web.dev〈Interaction to Next Paint (INP)〉〈https://web.dev/articles/inp〉〈2024〉]。這個「取最差值」的設計，是 INP 與 FID 最關鍵的工程差異。
把三段拆開才看得懂分數從哪裡來。Input Delay 是使用者輸入後、主執行緒空下來之前的等待，被長任務卡住時這段就飆高；Event Processing 是事件處理函式實際執行的時間，click handler 裡跑多少同步運算就反映在這；Presentation Delay 是處理完到下一次畫面繪製完成的時間，DOM 節點太多、佈局重算太重會把這段拖長。三段誰胖誰瘦，因站而異，也正是後面除錯時要分開看的理由。
取最差值而非平均值，是這套設計最狠的地方，它確保沒有任何一次互動卡爆，開發者不能再靠平均值把爛互動蓋掉。但有一個但書：當互動次數很多時，INP 的演算法會略過少數極端值，以免單一噪音主導整個分數 [來源：web.dev〈Interaction to Next Paint (INP)〉〈https://web.dev/articles/inp〉〈2024〉]。換句話說，INP 取的是高百分位數的那一次，並非絕對最差：在互動很少的頁面會接近最差，在互動很多的頁面會略做緩衝。一個 SPA 若整段使用期間累積了八十次互動，INP 會略過最高那幾次再取代表值；同一個頁面若使用者只點了三次，幾乎就是直接取最差。流量結構因此會左右你看到的 INP，工具採到的樣本分布本身就要先看清楚。要追這類細節，能撈現場請求與互動明細的工具會比只看總分有用得多，Chrome 內建的開發者工具則是定位單一卡頓互動最直接的方法。
同一個機制也解釋了實驗室與 Search Console 的落差：實驗室只跑一次固定腳本，互動次數少，幾乎等於取最差；真實使用者互動次數多，會被演算法略做緩衝，所以現場資料通常比實驗室好看，卻也更貼近使用者實際感受。要理解這層差異，可以先看一篇 JavaScript SEO 與渲染收錄，對主執行緒怎麼影響體驗會更有概念。
進階除錯：把卡頓互動拆到三段，找出真正兇手
知道 INP 取最差值之後，下一步是學會把那一筆最差互動拆開，看它到底卡在三段裡的哪一段。這是從「知道分數不好」走到「知道要改哪一行程式碼」的關鍵動作。Chrome DevTools 的 Performance 面板是最直接的顯微鏡，搭配較新的 long-animation-frames（loaf）API 與 web-vitals 程式庫的 attribution build，可以把現場每一次卡頓互動的成因歸因到具體的腳本與函式。
用 Performance 面板追單一互動的標準動作是這樣：打開 DevTools、切到 Performance 分頁、按下錄製、在頁面上重現那個卡頓操作（例如點開折疊面板或送出篩選條件）、停止錄製。錄製結果裡，主執行緒的活動會以火焰圖呈現，橫軸是時間。你要找的是被標成灰長條的長任務區塊，它對應的正是 input delay 飆高的時刻；接著看使用者輸入事件（在圖上會有黃色的事件標記）之後、下一次畫面繪製（綠色的 Paint 或紫色的大型 Layout 任務）之前，中間塞了什麼。把那段放大，火焰圖最寬的那幾層函式，通常就是 processing 段的元兇。
- 看主執行緒空窗：輸入事件之前若有一大段連續長任務，代表 input delay 被佔滿，兇手是背景腳本或還沒拆完的初始化工作。
- 看事件處理函式：輸入事件與下一個 paint 之間若有同步的大塊運算（排序、過濾、序列化），就是 processing 段在撐高分數。
- 看 Layout 與 Paint：處理完到畫面實際繪製完成之間若出現大型 Layout、Recalculate Style 或連續 Paint，presentation delay 就是病因，通常來自過多 DOM 節點或強制同步重排。
- 歸因到腳本：點開長任務的呼叫堆疊，記下是哪一個檔案、哪一個函式，以及它是不是第三方網域的腳本，這會決定你下一步是改自己的程式碼還是去跟第三方外掛談延後載入。
實驗室錄製雖然精準，但它只抓得到你剛好重現的那條路徑。真實使用者的卡頓往往藏在你沒料到的裝置、網速或操作組合裡，這時 long-animation-frames（loaf）API 就派上用場。loaf 會把每一筆超過 50 毫秒的長影格連同它的腳本來源、長任務明細一起送出，搭配 web-vitals 程式庫的 attribution 模式，能在生產環境採到「哪一個網域的腳本、哪一個函式」造成的 INP 卡頓。把這些現場明細按頁面、互動類型、裝置分組送進 GA4 或自建後端，你就能看出排名前幾名的卡頓來源是自己的程式碼還是第三方，而不需要憑直覺猜。要讀懂這些欄位，先熟悉 GA4 專有名詞列表 會讓採集回來的數字更容易對齊到業務決策。
實務上有個判讀細節值得記下：同一筆卡頓互動，input、processing、presentation 三段不見得同等肥。經常看到的型態是 input delay 偏高、processing 卻很短，這代表主執行緒在互動當下被別的工作佔住，你的事件處理函式本身沒問題，要對付的是佔住執行緒的那段背景任務；相對地，若 processing 段爆表、input delay 卻很乾淨，那就是你的 handler 裡塞了太重的同步運算。把三段數字擺在一起看，可以避免你花一週去優化根本不是瓶頸的那一段，這是「取最差值」這個設計在除錯層面帶來的紅利。
良好、需改善、不良的門檻認定
INP 分數多少才算過關？INP 在 200 毫秒以內為「良好」，200 到 500 毫秒為「需改善」，超過 500 毫秒為「不良」[來源：web.dev〈Defining the Core Web Vitals metrics thresholds〉〈https://web.dev/articles/defining-core-web-vitals-thresholds〉〈2024〉]。這組門檻是 Google 依使用者感知研究訂出來的，適用於整個 Core Web Vitals，不是隨便抓的數字。
| 評級 | INP 數值 | 第 75 百分位認定 |
|---|---|---|
| 良好（Good） | ≤ 200ms | 75% 的使用者都在這以內 |
| 需改善（Needs Improvement） | 200–500ms | 介於兩者之間，該修但不算爆 |
| 不良（Poor） | > 500ms | 超過四分之一使用者體感卡頓 |
門檻的認定方式很關鍵：是看第 75 百分位的現場資料（field data），不是單次實驗室測量 [來源：web.dev〈Core Web Vitals〉〈https://web.dev/articles/vitals〉〈2024〉]。意思是，至少要有 75% 的真實使用者 INP 落在良好區間，這個網站才會被判定為「良好」。這對小流量站是個壞消息，因為樣本少時，一兩個極端值就會把百分位數拉歪。對高流量電商反而是好消息，因為他們有足夠樣本讓百分位數穩定。
很多人會問：行動版跟桌面版門檻一樣嗎？答案是，門檻數字完全相同，良好都是 200ms 以內。但實測下行動版普遍難達標，因為手機 CPU 較弱、網路較不穩、第三方腳本又往往更多。所以同一個網站，桌面版 INP 漂亮、行動版不及格，是非常常見的狀況。Google 在排名時主要看行動版，行動版的排名與曝光因此直接牽動你的 SEO 表現。
Google 把頁面速度納入行動版排名訊號並非這兩年才開始的事。早在 2018 年 1 月官方就預告「Speed Update」，並自 2018 年 7 月起讓網頁速度正式成為行動搜尋的排名因素之一；這項更新只影響交付最慢體驗給使用者的頁面，且僅影響少數查詢 [來源：Google Search Central Blog (developers.google.com) 〈Using page speed in mobile search〉 https://developers.google.com/search/blog/2018/01/using-page-speed-in-mobile-search 2018-01-17]。理解這段背景，就會明白為什麼行動版 INP 特別值得盯緊：它正是這條「最慢體驗」評估鏈路上、目前負責互動段的官方指標。
把門檻背下來沒什麼用，真正該問的是「我網站最差的那一次互動，卡在三段裡的哪一段」。分數只是症狀，三段延遲才是病因；盯著分數修，就像盯著體重計節食，數字會動但身體不一定變健康。當你開始動手修，會發現連 Title Tag 撰寫技巧 這類看似無關的設定、或 robots.txt 對 SEO 的效果 這種爬取控制，都會透過「哪些資源被優先載入」間接影響開場的主執行緒負擔。門檻是驗收用的終點，真正該下手的地方是三段延遲。
把門檻落實到真實營運會碰到什麼狀況，可以用一個典型情境來看。以這類中型流量、商品列表與結帳頁為主的電商站為例，常見的狀況是：桌面版 INP 普遍落在約 150 到 250 毫秒之間，剛好踩在良好與需改善的交界，數字看起來還過得去；但行動版的第 75 百分位往往退到約 350 到 480 毫秒，直接掉進需改善區間，而且卡頓幾乎集中在結帳按鈕、數量增減與優惠碼輸入這幾個互動。依這類站的典型表現幅度約落在這個區間，並非單一網站的精確測量。把 web-vitals 採到的現場明細按頁面與互動類型分組，通常會看到結帳流程那幾個互動的 processing 段偏肥，元兇多半是事件處理函式裡同步跑的折扣與庫存計算。實務上常見的處理順序是：先抓結帳頁那一兩個最差互動做三段拆解，把重計算搬到 Web Worker 或預先算好，再把全站共用腳本從結帳流程獨立輕量打包，行動版 INP 會比全面重構更早看到回應。這裡也要誠實點出一個失敗模式：如果卡頓主要來自無權修改的第三方廣告或分析腳本，光改自家程式碼往往只能把數字壓低一截，第 75 百分位仍會卡在需改善區間的邊緣，這時與其反覆壓自家分數，不如評估把該類腳本延後載入或換成較輕量的替代方案，把有限的工程資源放在可控的那一段，才是務實的決策角度。
為什麼 Google 選 INP？為了揭露中後期卡頓、逼開發者顧全程
Google 用 INP 取代 FID，是因為 INP「取最差一次」的設計能抓出 FID 看不到的中後期卡頓，強迫開發者把每一次互動都優化順暢，光把開場做漂亮已經不夠。這背後是一個很清楚的價值判斷：使用者跟網站的互動不只一次，後續操作才是體驗的重點。
使用者在頁面上停留的時間越長，互動次數就越多，而每一次互動都可能遇到不同的卡頓來源。第一次點擊也許只是開個選單，主執行緒還很乾淨；但滾到中段、點開一個折疊面板、再送出一個表單時，DOM 已經膨脹、第三方腳本已經載入、事件監聽器已經疊了好幾層。這時候的卡頓，FID 完全無感，INP 卻會忠實記下。Google 要的就是這種忠實。把這件事放回整個內容生態看，搜尋意圖再精準、關鍵字研究終極指南 再完整，只要使用者點進來卻卡到受不了，後面再多的 內部連結打造網站架構 與 反向連結與網域權重 都救不回已經跳出的流量。體驗與內容其實是同一條漏斗的上下半段，談不上兩件事。
INP 同時涵蓋處理與畫面更新，這讓它更貼近「我點了、什麼時候看得到結果」的真實感受。取最差值的設計，讓任何一次卡頓都會反映在分數上，無法靠平均掩蓋；Google 的目標是從頭到尾都要順暢，而不只是開場順暢。搜尋意圖再怎麼精準，只要使用者點進來卡得受不了，跳出率照樣會告訴你真相。要拆解卡頓是怎麼把人推走的，先弄懂 網站跳出率是什麼 會讓你對互動流暢度更敏感；而這條從「點進來」到「願意留下」的鏈路，本質上就是 UI 與 UX 設計差異在體驗指標上的具體表現。
INP 會影響 SEO 排名。Core Web Vitals 是 Google 排名訊號之一，INP 上線後就取代 FID 成為「互動」這一塊的官方衡量。它不是排名的唯一因素，內容相關性與 E-E-A-T 高品質內容原則的權重通常更高，但當兩個網站內容勢均力敵時，體驗指標就會成為 tie-breaker。對電商這種轉換率敏感的站，INP 不良直接等於錢在漏；在 AI 時代的 SEO 趨勢裡，體驗指標的權重只會越來越高。想跟上這波變化，AI 搜尋時代的 SEO 全攻略 會幫你把體驗指標放進更大的策略框架裡。而當你的內容被 AI 摘要引用時，更要確保資訊本身正確，避免落入 AI 幻覺常見的錯誤 把錯誤數字散播出去。
把 INP 改善跟實際營收掛鉤，最直接的證據來自 Google 公開的案例：線上客運訂票平台 redBus 在改善網站的 Interaction to Next Paint（INP）後，銷售額增加了 7%。這個數字正好印證了上述「對電商而言 INP 不良等於錢在漏」的判斷，也說明 INP 從來不只是技術分數，而是會直接反映在結帳按鈕、表單互動這類轉換關鍵環節上 [來源：web.dev (Google) 〈Why does speed matter?〉 https://web.dev/articles/why-speed-matters 2026]。
同一份 Google 整理的案例把 Core Web Vitals 當成一組來看，效益更立體。樂天網購（Rakuten 24）投入改善 Core Web Vitals 後，每位訪客營收提升 53.37%，轉換率提升 33.13%；電信商 Vodafone 把 LCP 改善約 31%，銷售額跟著提升 8%；經濟時報（The Economic Times）通過 Core Web Vitals 門檻後，整體跳出率改善 43% [來源：web.dev (Google) 〈Why does speed matter?〉 https://web.dev/articles/why-speed-matters 2026]。把這幾個數字擺在一起，可以歸納出一個務實的判斷：載入速度（LCP）負責把人送進門、互動順暢度（INP）負責把人留在結帳流程裡、視覺穩定度（CLS）負責不讓人在按下按鈕那一刻點錯。三段漏斗缺一不可，而 INP 對應的正是轉換率最敏感的那一段。對流量主要來自行動裝置的站更是如此，畢竟行動版同時背著較弱的 CPU 與較不穩的網路，互動卡頓在這個裝置上最容易被放大成結帳放棄。
把這些案例轉成可操作的判讀原則：當你看到現場 INP 落在 200 到 500 毫秒的「需改善」區間，先別急著全面重構，因為這段往往只卡在一兩個關鍵互動（結帳按鈕、篩選器展開、數量增減）。把 web-vitals 採到的 INP 事件依頁面與互動類型分組，找出第 75 百分位被哪一類互動撐高，再對那個互動做三段拆解，投資報酬率會遠高於無差別優化。多數電商的經驗是，結帳流程的 INP 只要能壓進良好區間，後續的轉換率與客單價都會給出可量測的回應。
INP 取最差一次而非平均值，這個設計是為了確保沒有任何一次互動卡爆，開發者不能再靠開場漂亮掩蓋中後期卡頓。Google 自 2024 年 3 月起以 INP 正式取代 FID 成為 Core Web Vitals 穩定指標，良好門檻為 200 毫秒以內、不良為超過 500 毫秒 [來源：web.dev〈Interaction to Next Paint (INP)〉〈https://web.dev/articles/inp〉〈2024〉]。
量 INP 的工具分工
量 INP 要分兩種情境：實驗室測試用 Lighthouse 或 PageSpeed Insights 看單次模擬，真實使用者資料則看 Search Console 的 Core Web Vitals 報表與 web-vitals 程式庫採集的現場資料。兩種不能混為一談，因為 INP 取的是最差一次，現場資料比實驗室重要得多。
| 工具 | 類型 | 適合看什麼 |
|---|---|---|
| PageSpeed Insights | 實驗室 + 現場 | 同時給 Lighthouse 模擬分數與 CrUX 真實使用者資料 |
| Lighthouse | 實驗室 | 單次模擬、適合本地反覆測 |
| Search Console CWV 報表 | 現場 | 第 75 百分位現場表現、28 天滾動 [來源：Google Search Console〈Core Web Vitals report〉〈https://support.google.com/webmasters/answer/9205520〉〈2024〉] |
| web-vitals 程式庫 | 現場 | 在自家網站採集每位使用者 INP，可送到 GA4 或自建後端 |
| Chrome DevTools Performance | 實驗室 | 拆三段延遲、定位長任務 |
PageSpeed Insights 是最常見的起點，因為它一個頁面同時給你實驗室分數與 CrUX 現場資料，可以一眼看出兩者落差。如果你連 Search Console 安裝教學 都還沒跑過，強烈建議先裝起來，因為它的 CWV 報表顯示的是第 75 百分位的現場表現，這才是 Google 用來評分的數字。實驗室分數再漂亮，現場不及格就是不及格。如果你還在找順手的檢測平台，網站速度測試工具比較 把幾個免費方案整理在一起，挑一個能同時給實驗室與現場數字的會省事很多。
web-vitals 程式庫是進階情境的主力。它可以在自家網站上採集每一位真實使用者的 INP，把數字送到 GA4 或自建後端，補上 Search Console 看不到的明細。Search Console 的數字是 28 天滾動的聚合，看到問題時往往已過了一個月；web-vitals 則能即時抓到哪一種裝置、哪一個頁面、哪一段互動最卡，這對除錯來說是天差地別。把採集到的欄位跟 排名與曝光關係研究 對著看，會發現 INP 不良的頁面往往曝光沒問題、點擊卻先崩；把 INP 分位數直接畫成儀表板，比盯單一總分更能看出問題。
還有一個常被忽略的細節：實驗室測試的 INP，取的幾乎是當次腳本裡的最差互動，所以數字通常偏悲觀；而 CrUX 與 web-vitals 採的是真實分布，會略過極端值。所以如果你看到 PageSpeed Insights 上實驗室 INP 是 450ms、現場卻只有 180ms，先別高興，那只代表你的測試腳本剛好踩到了一個多數使用者不會碰到的路徑。真正該看的，永遠是現場資料。
把測量這件事放回整站地圖看，INP 不會憑空卡，它常常是被整體技術健康度拖下水。流量結構一旦偏掉，你採到的 INP 樣本也會跟著偏，因為不同關鍵字帶來的使用者行為完全不同；測量 INP 之前，先把關鍵字佈局與內容分類這些地基清乾淨，你看到的數字才會誠實。
INP 不及格時的下手順序
INP 分數太差時，先找出是 input delay、processing 還是 presentation delay 拖累分數，最常見的兇手是主執行緒上的長任務（long task）與過重的第三方腳本；方向是拆任務、延後載入、減少主執行緒阻塞。動手前先量，是唯一不會走冤枉路的原則。
長任務的官方定義是超過 50 毫秒的同步任務 [來源：web.dev〈Optimize long tasks〉〈https://web.dev/articles/long-tasks-devtools〉〈2024〉]。這種任務會獨占主執行緒，在它跑完之前，使用者的任何輸入都得排隊，input delay 因此飆高。用 Chrome DevTools 的 Performance 面板錄一段操作，把右上的長任務（會被標灰長條）找出來，通常就是第一個要對付的目標。
- 定位：用 DevTools Performance 或 web-vitals 拆出三段延遲，看是哪一段最胖。
- 找長任務：抓出 >50ms 的同步任務，這通常就是 input delay 的元兇。
- 拆任務：用 scheduler.yield、setTimeout、requestIdleCallback 把大任務切成小塊，讓主執行緒有機會喘氣回應輸入。
- 延後載入：非關鍵的第三方腳本（廣告、聊天外掛、A/B 測試）改成 lazy load 或 defer，別讓它們搶第一秒。
- 減 DOM：presentation delay 高常因為節點太多或佈局重算太重，虛擬捲動與避免同步強制重排是常見解法。
第三方腳本是隱形兇手裡最難搞的一類。廣告、分析、客服聊天外掛、社群分享按鈕，這些看起來無害的小東西，常常在主執行緒上插了一堆同步監聽器。以常見的客服聊天外掛為例，只要把它的載入時機從開場延後到使用者真正需要時，行動版 INP 從約 720ms 掉到約 240ms 的幅度並不罕見，前後往往只動了一行載入設定。排查第三方腳本時，可以搭配 SEO 工具軟體推薦 裡的第三方請求分析功能，會比肉眼快很多。特別要留意的是結構化標記類的設定，像 結構化資料用途介紹 裡的 JSON-LD 雖然不卡主執行緒，但有些外掛會把它跟同步腳本綁在一起載入，反而拖累開場的 JavaScript 渲染與收錄。把腳本清單跟 Canonical 解決重複內容 的設定一起盤點，常常會挖出意料之外的重量級兇手。
事件處理函式裡的同步運算與 DOM 操作，是另一個常見來源。如果你在 click handler 裡同步跑一段排序、過濾、再一口氣操作幾百個 DOM 節點，processing 段就會爆。方向是把重運算搬到 Web Worker，或用 requestAnimationFrame 分批更新 DOM。這些手法本質上都是網頁速度優化方法的延伸，只是現在要特別留意「取最差一次」這個特性，因為只要有一次沒拆好，整個 INP 就會被它拖下去。把非關鍵資源挪到該出現時才載入，是延後主執行緒負擔的有效手段，Lazy Loading 延遲載入實戰指南 把做法講得很細，能直接套用到腳本與圖片上。
presentation delay 高，通常是佈局重算（layout）與大量 DOM 節點造成。一個畫面上幾千個節點的長列表，每次互動都會觸發整棵樹重排，畫面自然繪製得慢。解法不外乎虛擬捲動、減少巢狀、避免讀取會觸發同步重排的屬性（像 offsetWidth）。如果你有用結構化資料那類的 JSON-LD，記得它們是靜態文字、不會拖累主執行緒，不用列入 INP 嫌疑犯；想把這類標記寫對、讓搜尋引擎讀懂你的內容，可以對照 結構化資料 Schema 標記教學。
不同技術架構下的 INP 地雷與對策
INP 卡頓的位置與成因，會隨網站的技術架構而長得很不一樣。同一套「拆任務、延後載入、減 DOM」的大方向，落到 SPA、多頁式網站、內容管理系統或伺服器端渲染框架上，要下手的位置完全不同。先判斷自己的站屬於哪一類，能省下大量走冤枉路的時間。
| 架構類型 | 最常見的 INP 卡點 | 首要對策 |
|---|---|---|
| 傳統多頁式網站（MPA） | 開場載入大量第三方腳本，第一次互動前主執行緒被佔滿 | 延後載入非關鍵腳本、清理未使用的外掛 |
| 單頁應用（SPA） | 路由切換與大型狀態更新觸發的同步重算，後續互動 DOM 不斷膨脹 | 把重運算搬進 Web Worker、狀態更新分批、長列表虛擬捲動 |
| 伺服器端渲染框架（Next.js、Nuxt 等） | hydration 期間主執行緒被佔住，使用者此時互動會卡 | 延後或部分 hydration、拆分打包體積、避免同步取得大量資料 |
| 內容管理系統（WordPress 等） | 佈景主題與外掛載入大量同步腳本，前端函式庫重複載入 | 停用多餘外掛、合併與延後載入腳本、更換輕量佈景 |
| 電商結帳頁 | 結帳按鈕的事件處理函式同步跑價格與庫存計算，觸發整頁重排 | 把計算搬出事件處理函式、結帳流程獨立輕量打包 |
伺服器端渲染框架的 hydration 是一個特別值得留意的隱形兇手。頁面在伺服器先把 HTML 送出來、畫面很快出現，但瀏覽器接著要把那份 HTML 重新接上 JavaScript 事件，這段 hydration 過程會在主執行緒上跑一段不算短的工作。如果使用者在這段期間點擊頁面，那次互動的 input delay 就會被 hydration 工作佔滿，INP 因此飆高。打包體積越大、hydration 越重，這個視窗就越長。方向是把首屏所需 JavaScript 縮到最小、對非關鍵元件延後或部分 hydration，讓主執行緒盡早空出來回應使用者。這類框架常見的迷思是「伺服器渲染就一定快」，但就 INP 而言，伺服器渲染只解決了載入那一段，互動段的順暢度仍取決於前端 JavaScript 多快把執行緒還給使用者。
單頁應用的地雷則集中在「使用越久、DOM 越胖」。隨著使用者切換路由、展開摺疊面板、累積清單項目，事件監聽器會層層疊上去，狀態樹也越來越大。每一次互動都可能觸發整棵元件樹的重新計算與重排，INP 自然越用越差。這類網站特別適合把昂貴的運算（排序、過濾、資料轉換）搬進 Web Worker，讓主執行緒只負責回應輸入與更新畫面；同時用虛擬捲動限制畫面上實際存在的 DOM 節點數量，把 presentation delay 壓在合理範圍。這些手法都與 網頁速度優化方法 一脈相承，只是對 SPA 要特別盯著「取最差一次」這個特性，因為只要某一次路由切換沒處理好，整個工作階段的 INP 就會被它定義。
內容管理系統架構的網站，麻煩通常出在「看不見的腳本堆疊」。一個佈景主題加上幾個外掛，前端很容易就載入了好幾份 jQuery、多個頁面構建器，以及一堆社交分享與分析的同步腳本。這些腳本各自不重，但疊起來會在主執行緒上插滿同步監聽器，第一次互動與後續每一次互動都被拖累。方向是逐一停用、再觀察現場 INP 的變化，留下真正有貢獻的外掛，其餘改成延後載入或直接移除。把這類清理跟 robots.txt 對 SEO 的效果 的爬取控制一起盤點，往往能同時改善收錄效率與互動體驗。
電商結帳頁是 INP 影響營收最直接的地方。結帳按鈕、數量增減、優惠碼輸入這些互動，常常在事件處理函式裡同步跑折扣計算、庫存查詢與整頁重排。使用者按下去到畫面回應之間只要超過半秒，放棄結帳的機率就會明顯上升。方向是把計算結果預先算好或在背景算好、互動當下只做輕量的狀態切換與畫面更新；結帳流程的 JavaScript 也要獨立輕量打包，不要把首頁用得到的全站腳本全部背進來。把這個原則記下來，再去對照 網站快取 Cache 機制 的資源分層，會發現快取顧好載入、事件處理函式顧好互動，兩邊合力才能把結帳這段漏斗補滿。
什麼情況不必急著優化 INP
把 INP 當成萬靈丹也會走偏。有些情境下，過早優化 INP 反而會排擠更重要的工作，或花了大力氣卻看不到排名與營收回應。誠實地畫出邊界，才知道什麼時候該收手、把資源挪到別處。下面幾種狀況，INP 通常不是你該最先動手的地方。
- 樣本不足以判讀：Search Console 的 CWV 報表需要夠多的現場資料才會穩定，小流量站往往顯示「資料不足」。這時實驗室分數再難看，也無法直接推論成排名風險，先把內容與收錄這些地基顧好，等樣本累積再回頭看 INP。
- 內容還沒站穩：一個連基本關鍵字佈局與資訊架構都還沒成形的站，體驗指標的排名紅利拿不到。把心力先投在 關鍵字研究終極指南 與內容品質，比把 480 毫秒硬壓到 180 毫秒更能帶動排名。
- 已經穩定落在良好區間：當現場第 75 百分位長期落在 200 毫秒以內，邊際效益會快速遞減，繼續往下壓的分數對使用體感與排名都難再產生可量測的回應。這時資源挪去補 CLS 或 LCP，整體體驗收益更高。
- 卡頓來自無法控制的第三方：某些廣告或分析腳本由合作單位管理，你無權修改。這時與其反覆優化自家程式碼，不如先把可控的部分做到極致，並評估能否延後載入或改用較輕量的替代方案。
畫一張更明確的優先順序判斷表，把 INP 放進整個體驗與 SEO 工程的全景。這張矩陣把「問題嚴重程度」與「可控制程度」擺在兩軸，幫你決定下一筆工程預算該投到哪一格。
| 情境 | 嚴重程度 | 可控制程度 | 建議優先順序 |
|---|---|---|---|
| 頁面未被收錄 | 致命 | 高 | 最先處理，收錄是一切的前提 |
| LCP 不良（載入太慢） | 高 | 高 | 緊接其後，先讓人進得了門 |
| CLS 不良（畫面亂跳） | 高 | 高 | 與 INP 並列，影響點擊與信任 |
| INP 落在不良區（>500ms） | 高 | 中 | 對電商與表單密集頁優先修 |
| INP 落在需改善（200–500ms） | 中 | 中 | 挑關鍵互動修，不必全面重構 |
| INP 已在良好（≤200ms） | 低 | 低 | 維持監控，資源挪到其他指標 |
這張矩陣的核心觀念是：體驗指標彼此會牽動，修 LCP 常順帶讓主執行緒在開場空出來，INP 跟著受益；先修 CLS 則能避免使用者每次點擊都點到錯位置。把工程資源依嚴重程度與可控制程度排序，才能避免在邊際效益最低的那一格耗掉一整季。當你決定要動手修 INP，記得同步回頭看 網站速度優化全攻略 的整站視野，把單點優化放進資源載入的全盤計畫裡。
INP 在 Core Web Vitals 裡的位置：與 LCP、CLS 的分工
INP 跟 LCP、CLS 這些指標有什麼關係？Core Web Vitals 三本柱是 LCP（載入速度）、INP（互動流暢度）、CLS（視覺穩定度），INP 取代 FID 後負責「互動」這一塊，三者合起來才完整描述使用者從進站到操作全程的體驗。想快速建立整體概念，可以回頭讀一篇 Core Web Vitals 的白話文介紹。
| 指標 | 衡量什麼 | 良好門檻 |
|---|---|---|
| LCP（Largest Contentful Paint） | 最大元素何時畫完，衡量「載入」 | ≤ 2.5s [來源：web.dev〈Largest Contentful Paint (LCP)〉〈https://web.dev/articles/lcp〉〈2024〉] |
| INP（Interaction to Next Paint） | 互動到畫面更新多久，衡量「互動」 | ≤ 200ms |
| CLS（Cumulative Layout Shift） | 元素有沒有亂跳，衡量「視覺穩定」 | ≤ 0.1 [來源：web.dev〈Cumulative Layout Shift (CLS)〉〈https://web.dev/articles/cls〉〈2024〉] |
三個指標各有分工，也互相牽動。LCP 慢，通常代表資源載入有問題，連帶會讓主執行緒在開場被佔滿，INP 跟著遭殃；CLS 高，代表元素一直跳，使用者每次點擊都點到錯位置，互動體驗一樣崩壞。所以修 INP 時常常會順帶動到其餘兩個，Core Web Vitals 才會建議一起看，別只盯著單一數字。資源載入這條線尤其值得先顧好，把靜態資源交給 網站快取 Cache 機制 處理，主執行緒在開場就不會被各種請求塞滿，INP 與 LCP 通常會一起改善。
INP 上線後，CWV 從「LCP + FID + CLS」變成「LCP + INP + CLS」這組合，FID 正式退役。但這不表示 FID 的歷史資料消失，GSC 常用功能 裡官方仍會提供過去的 FID 資料供參考，只是它已經不再參與排名計算。FID 不用再拿來評分，但可以當歷史對照，看你的網站這幾年互動體驗是進步還是退步。而要讓 Google 穩定收錄這些持續更新的頁面，網站 Sitemap 入門指南 是把提交機制先顧好的基本功。
把這組指標放回更大的地圖來看，Core Web Vitals 只是 Google 衡量體驗的一環，它跟確認網頁被 Google 索引、爬取預算優化、XML Sitemap 幫助收錄這些技術基礎是同一條鏈上的事。體驗指標再漂亮，頁面沒被收錄也是白搭；收錄很健康但體驗崩壞，排名同樣上不去。兩邊都要顧，這才是 獲得自然搜尋流量的方法 的完整樣貌。
第一線最常被問的 INP 細節
下面幾題挑的是正文沒有單獨展開、但實務判讀時常卡住的地方；基礎定義與門檻數字在前段已交代，這裡不重複。想把觀念落地，網頁開發者工具 F12 的實機操作是最快的路徑。
實驗室測的 INP 跟 Search Console 差很多，該信哪個？
信現場資料。實驗室只跑一次固定腳本，互動次數少，幾乎等於取最差值，數字偏悲觀；真實使用者的互動次數多，會被演算法略過少數極端值再取代表值。Google 用來評分的是第 75 百分位的現場資料，所以判讀永遠以現場為準，實驗室拿來定位單一卡頓互動就好。
INP 的「取最差值」會被極端值綁架嗎？
互動次數少時接近絕對最差，互動次數多時會略過最高那幾次再取代表值，屬於高百分位數而非絕對最大值。這也是同一個頁面在 SPA（累積數十次互動）與落地頁（只點兩三次）上，INP 判讀邏輯不能套同一套的原因。
不同網站架構的 INP 卡點都一樣嗎？
不一樣。多頁式網站常卡在開場載入太多第三方腳本；單頁應用常卡在路由切換與 DOM 膨脹後的同步重算；伺服器端渲染框架常卡在 hydration 佔住主執行緒的那段視窗；內容管理系統常卡在外掛堆疊出的同步監聽器。先判斷自己屬於哪一類，再決定從 input、processing 還是 presentation 下手，會比無差別優化有效。
卡頓來自無法修改的第三方腳本時怎麼辦？
光改自家程式碼通常只能把數字壓低一截，第 75 百分位仍會卡在需改善邊緣。務實的做法是評估把該類腳本延後載入或換成較輕量的替代方案，把有限工程資源放在可控那一段；當卡頓主要來自廣告或分析腳本時，與其反覆壓自家分數，重新談載入時機的投資報酬率通常更高。
除了 DevTools，還有什麼工具能找出 INP 卡在哪一段？
Chrome 較新的 long-animation-frames（loaf）API 會把每一筆超過 50 毫秒的長影格連同腳本來源一起送出，搭配 web-vitals 程式庫的 attribution 模式，能在生產環境採到「哪一個網域的腳本、哪一個函式」造成的卡頓，把現場明細按頁面、互動類型、裝置分組送進後端，就能看出排名前幾名的卡頓來源，而不必憑直覺猜。
INP 本質上只是 Google 用「取最差一次」這個設計，把一個早就存在、卻被 FID 掩蓋的真相還原出來：使用者要的是全程順暢，開場漂亮只是基本款。把這層邏輯弄通，再回頭看 Google 搜尋技巧、研究 Google AI 摘要怎麼勝出，或佈局 Google AI 模式新搜尋，遇到體驗相關的取捨時會有更清楚的判斷依據。