INP 優化完整指南：從 GSC 警告到 DevTools 診斷，三個延遲階段的修復方法

如果你在 Google Search Console 看到「INP 問題：超過 200 毫秒（行動版）」的警告，這篇文章正是為你寫的。INP（Interaction to Next Paint，與下一個顯示內容的互動）是 Google Core Web Vitals 的互動回應性指標，2024 年 3 月起正式取代 FID，成為影響網頁體驗評分的關鍵指標之一。排查 INP 問題的難點不是「知道什麼是 INP」，而是「不知道從哪裡下手」，大多數教學直接跳到程式碼，但真正的診斷流程應該從 GSC 警告開始，一層一層往下追。本文根據實際優化案例，整理出一套完整的 INP 診斷與修復流程，從 GSC 到 DevTools 到具體修復，以及不需要等 28 天 CrUX 更新的驗證方法。

INP 是什麼：測量使用者互動到下一個畫面的延遲

INP 測量的是：從使用者對網頁執行操作（點擊、輕觸、按鍵），到瀏覽器繪製出下一個畫面回應的時間。這個時間越短，代表網站對使用者操作的反應越靈敏。INP 的分數是從使用者整個瀏覽過程中，所有合格互動的延遲時間計算而來，取第 98 百分位數（互動次數超過 50 次時）。

INP 計入的互動類型只有三種：滑鼠點擊、觸控螢幕輕觸、實體或螢幕鍵盤按鍵。滑鼠懸停（hover）和頁面滾動不計入 INP，因為這兩種操作由合成器執行緒獨立處理。

INP 取代 FID 的原因是 FID 只測量「第一次」互動的輸入延遲，忽略了網站後續所有互動的品質。一個首次點擊很快但後續操作卡頓的頁面，FID 可能顯示良好，但使用者體驗其實很差。INP 監測整個瀏覽生命週期內所有互動，評估更全面。Google 在 Search Central 部落格中說明了 INP 取代 FID 的原因與過渡時程。

INP 的三個延遲階段：哪個才是真正的瓶頸

每一次使用者互動的延遲，都可以拆成三個連續階段。弄清楚哪個階段佔最多時間，是選擇正確修復方向的前提，否則容易花時間優化了錯的地方。

數據顯示 Presentation Delay 平均佔總 INP 延遲的 42%，是最常被忽略但影響最大的階段。很多人花時間優化 JavaScript 執行時間，結果 INP 改善有限，問題可能出在 DOM 規模或 CSS 複雜度上。

GSC 出現 INP 警告，排查流程從哪裡開始

排查流程的起點是 Google Search Console，不是 PageSpeed Insights，更不是直接修改程式碼。GSC 的 CWV 報告顯示的是真實使用者的 CrUX 現場資料，能告訴你哪些頁面、哪些裝置出問題；PSI 和 DevTools 則是用來定位根本原因。

建議依照以下順序操作：

有個常見錯誤是只看 PSI 的 Lighthouse 跑分（lab data），因為 lab data 是模擬環境，不反映真實使用者的互動行為。INP 是現場指標（field metric），一定要先確認 CrUX 資料後再動手，否則可能修了 lab data 但 GSC 的 INP 問題還是不消。

INP 優化涵蓋網站整體效能，與 Core Web Vitals 三大指標的診斷方法密切相關，建議先確認三個指標各自的狀態再決定優先順序。

用 Chrome DevTools 定位 INP 卡在哪個階段

打開 DevTools（F12），切到 Performance 分頁，點「Start profiling and reload page」錄製一次包含使用者操作的 trace，然後在錄製過程中執行你想測試的互動（例如點選下拉選單、送出表單）。錄製完成後在 trace 裡找「Interactions」軌道，可以看到每一次互動的完整時序。

以下是看 trace 的方法：

• Input Delay 過長：在互動發生前，主執行緒上有一段黃色的長任務（Long Task，超過 50ms）。這段任務結束後，瀏覽器才開始處理你的互動事件。長任務可能是第三方腳本、大型 JavaScript bundle，或者 setInterval 重複觸發的計算。
• Processing Duration 過長：Interactions 軌道裡，事件回調本身佔用時間很長。點開這段，看哪個函式的 Self Time 最高，通常是複雜的事件處理邏輯、連鎖的 DOM 操作、或者 layout 抖動（Layout Thrashing）。
• Presentation Delay 過長：事件回調很快結束，但後面有一大塊 Recalculate Style 或 Layout 計算。這通常是 DOM 過大或 CSS 選擇器過複雜造成的。

如果不確定哪個問題最嚴重，可以先看 PSI 的「Diagnostic」區塊，「Reduce the impact of third-party code」和「Avoid long main-thread tasks」這兩項出現時，基本上是 Input Delay 的問題；「Minimize main-thread work」指向 Processing Duration；「Avoid large layout shifts」或「DOM size is too large」則指向 Presentation Delay。

這個追蹤方式和 JavaScript 渲染對 SEO 的影響中討論的主執行緒阻塞問題直接相關，有時候同樣的 JS 問題同時影響 INP 和索引收錄。

Input Delay 怎麼修：找出阻塞主執行緒的長任務

Input Delay 的根本原因是主執行緒被長任務（Long Task）佔住，使用者的互動事件必須等待長任務結束才能被處理。修復方向有三個：分解長任務、延遲非關鍵腳本、將計算移至 Web Workers。

關於 Input Delay 優化的更多技術細節，web.dev 的 INP 優化指南有詳細說明各種讓出主執行緒的方法。一個常被忽略的問題是 setTimeout(..., 0) 和 scheduler.yield() 的行為差異。用 setTimeout 分割任務時，後續的任務會被放到任務佇列的最尾端，優先級下降；scheduler.yield() 則讓出主執行緒後，繼續維持原本的高優先級，更適合用在使用者互動觸發的重要任務裡。

Processing Duration 優化：事件處理器裡只做最少的事

Processing Duration 變長的原因通常是事件處理函式做了太多工作，驗證輸入、觸發 API 請求、更新大量 DOM 元素全都放在同一個回調裡執行。核心原則是：事件處理器只負責「讓使用者立刻看到視覺回饋」，其他工作延後處理。

搜尋框輸入是最典型的例子。每次鍵盤輸入都觸發完整的搜尋請求和 DOM 更新，Processing Duration 會很長。修法是先立刻更新輸入框的顯示狀態（使用者感受到回應），然後用 debounce 將後續的搜尋請求延後 200-300ms 才觸發。

另一個常見問題是 Layout Thrashing（佈局抖動）：JavaScript 交錯讀取和寫入 DOM 樣式，迫使瀏覽器在單一幀內多次重新計算佈局。例如在迴圈裡先讀取 element.offsetWidth 再設定 element.style.width，再讀取再設定，這樣每一次讀取都會觸發強制同步佈局計算。修法是先批量讀取所有要用的樣式值，再批量寫入，或改用 CSS transform 代替直接操作 layout 屬性。

Presentation Delay：DOM 太大跟 CSS 複雜度怎麼影響 INP

Presentation Delay 是最容易被忽略的階段。即使事件回調執行很快，如果 DOM 規模過大或 CSS 選擇器過複雜，瀏覽器在計算樣式和執行 layout 時就會耗費大量時間，導致呈現延遲拉長。

在 DevTools 裡可以這樣確認 DOM 規模：Console 輸入 document.querySelectorAll('*').length，超過 1,400 個節點時 Presentation Delay 開始顯著增加，超過 3,000 個節點時影響會很明顯。

值得注意的是，content-visibility: auto 可以讓瀏覽器跳過畫面外元素的渲染計算，對長頁面的 Presentation Delay 改善效果明顯，但對含有廣告的頁面需要測試，避免版面計算出現問題。

WordPress 網站 INP 優化：不需要寫程式的實戰清單

WordPress 的 INP 問題大多來自主題載入的大量 JavaScript、過多的外掛腳本，以及第三方服務（廣告、客服機器人、追蹤碼）阻塞主執行緒。以下清單可以在不修改程式碼的情況下執行：

1. 啟用效能外掛的 Defer JS 功能：WP Rocket、LiteSpeed Cache、W3 Total Cache 都有「Delay JavaScript Execution」選項。啟用後，非關鍵 JS 等到使用者互動後才載入，能顯著降低 Input Delay。
2. 停用不需要的外掛腳本：Perfmatters 或 Asset CleanUp 可以讓你指定哪些頁面不載入特定外掛的 CSS 和 JS。每個外掛都可能在每個頁面載入，實際上大多數頁面只用到少數功能。
3. 延遲 Google Tag Manager 的觸發時機：GTM 的觸發條件改為「DOM ready」或「Window loaded」，而不是「Page view」，可以推遲 GTM 容器內所有腳本的執行時機。
4. 停用 WordPress 預設的 jQuery Migrate：多數現代主題和外掛不再需要 jQuery Migrate。可以用外掛（例如 Disable jQuery Migrate）移除這個舊版相容性腳本。
5. 停用 WordPress Emoji 腳本：WordPress 預設載入 Emoji CSS 和 JS，大多數網站不需要。在 functions.php 加一行或使用 Disable Emojis 外掛移除。
6. 審查 Gutenberg 區塊腳本：Gutenberg 的每個區塊都可能載入自己的前端 JavaScript。如果頁面上有很多不同的區塊，逐一確認哪些區塊實際有用到互動功能。
7. 客服小工具改為使用者點擊後才載入：Intercom、Zendesk、Tidio 等客服機器人預設在頁面載入時就初始化。改為使用者點擊特定按鈕後才載入（懶載入觸發）可以大幅降低主執行緒負擔。

執行這份清單後，用 PageSpeed Insights 重新跑一次，觀察「Reduce JavaScript execution time」和「Avoid long main-thread tasks」的警告有沒有消失或數字下降。這個方向與 LCP 優化有一定重疊，因為第三方腳本同時影響 LCP 和 INP。

優化完之後怎麼確認 INP 真的改善了

INP 是現場指標，CrUX 資料每 28 天滾動更新一次，GSC 的 CWV 報告反映的是過去 28 天的平均值。修改完之後，不可能馬上在 GSC 看到 INP 變「良好」。但有幾個方法可以更快確認改善有效：

最快的驗證方式是在 Console 載入 web-vitals.js，然後在頁面上執行多次點擊等互動操作，Console 會輸出當前的 INP 值。這不是 CrUX 的統計數據，但可以確認修改方向是否有效，不需要等 28 天。

完成本地驗證後，記得回到 GSC 查看 GSC 的 Core Web Vitals 報表，確認問題頁面的狀態有從不佳移往需改善方向，這通常在修改部署後 3-7 天可以觀察到初步變化。

INP 優化常見誤區：這幾件事多數人理解錯了

INP 優化有幾個容易被誤解的地方，如果沒有先搞清楚，很容易花了好幾天時間排查，最後卻發現優化方向不對。以下整理了實際案例中最常見的幾個誤解：

• 以為 Lighthouse 分數高等於 INP 良好：Lighthouse 的 Performance 分數不直接反映 INP，因為 Lighthouse 在模擬環境下跑，沒有真實的使用者互動。INP 必須看 CrUX field data，不是 lab score。
• 以為優化 LCP 就能順帶改善 INP：LCP 和 INP 是兩個不同的階段，LCP 是初始載入，INP 是後續互動。圖片壓縮或伺服器回應速度對 LCP 有幫助，但對 INP 幾乎沒有直接效果。
• 以為只有行動版才有問題：GSC 通常是行動版先出現 INP 警告，因為行動裝置 CPU 較弱，長任務執行時間更長。但電腦版的 INP 也可能不良，只是閾值內的容忍度較高，GSC 不一定會標示出來。
• 以為刪除 JavaScript 就能解決：盲目刪除腳本可能破壞功能。正確做法是用 DevTools Coverage tab 確認哪些 JavaScript 在首次互動時實際被執行，再判斷哪些可以延遲或移除。
• 以為 INP 改善後 GSC 馬上更新：如前面說的，GSC 的 CWV 報告是 28 天滾動資料。修復後要等一段時間觀察趨勢，不要因為 GSC 沒有立刻「解決」就懷疑修復無效。

最後一點：用爬取工具檢查頁面的腳本載入情況，有時候可以幫助快速識別哪些頁面載入了大量第三方資源，作為 INP 排查的初步資料。

關於如何識別與處理影響效能的第三方腳本管理，可以參考第三方腳本 SEO 診斷指南。

小結：INP 優化的優先順序

INP 問題通常不是單一原因造成的，但排查順序很重要：先從 GSC 確認影響範圍，用 PSI 確認 CrUX 現場資料，再用 DevTools 定位到具體的延遲階段，然後針對最長的那個階段優先修復。WordPress 網站可以先從外掛腳本管理和第三方延遲載入下手，通常能在不寫程式的情況下看到明顯改善。修復後用 DevTools 或 web-vitals.js snippet 驗證，不需要等 28 天 CrUX 更新才能確認方向是否正確。

如果三個階段都有問題，通常 Input Delay 和 Presentation Delay 的修復效益最高，Processing Duration 則相對容易針對具體函式進行優化。INP 的門檻是 200ms，但在實際優化工作中，能把 INP 壓到 150ms 以下，使用者才不容易感受到任何延遲。

延伸閱讀：若你的站點剛遷移或進行過重大改版，建議同時確認 Core Web Vitals 三大指標的整體狀態，避免修了 INP 卻讓 LCP 或 CLS 出現退步。

用 PageSpeed Insights 診斷 確認 INP 欄位資料後， 再根據本文的 DevTools 流程找出長任務根因。