2024 年中 Google 把互動到下次繪製（Interaction to Next Paint，INP）正式納入核心 Web 指標（Core Web Vitals，CWV）後，這個指標就成了站長最頭痛的關卡。最大內容繪製（LCP）與累積版面位移（CLS）通常還在綠燈範圍，INP 一打開 PageSpeed Insights 就紅得刺眼。

2026 年的數字更直接。全球網站約有 43% 在 INP 未達 200 毫秒的「良好」門檻，是三項核心 Web 指標中失敗率最高的一項。對 WordPress 站長來說，問題更尖銳——主流佈景搭配多個外掛、頁面建構器與第三方追蹤碼，幾乎都會把工作量堆在瀏覽器主執行緒上。使用者按一個按鈕、切一個分頁、展開一層選單，都要等主執行緒處理完一串長任務才有反應。

這篇要拆解的，是 wordpress inp 優化的核心邏輯。為什麼互動延遲幾乎全部源自主執行緒被佔用，可以從哪些訊號定位卡點，以及把延後 JavaScript、拆分長任務、節流事件處理、控制 DOM 節點這幾件事，按什麼順序處理才有效。

INP 為什麼成為 2026 最常被擋下的核心指標

INP 量的不是頁面開啟速度，而是「使用者點下去之後，畫面多久才有回應」。Google 取的是整個瀏覽期間最長的一次互動延遲（極端值有過濾），再用 Chrome User Experience Report（CrUX）28 天滾動平均回報到 PageSpeed Insights。門檻是 200 毫秒以下良好、200 至 500 毫秒待改善、超過 500 毫秒視為差。

這項指標 2024 年才取代第一次輸入延遲（FID）。FID 只看第一次互動，多數站台輕鬆過關，許多人因此誤以為網站互動體驗沒問題。INP 改成抓最長的一次互動後，過去被忽略的問題全部浮上檯面——展開行動選單、切換商品變化、加入購物車、點 AJAX 篩選，這些動作只要中間有任何一段拖到 300 毫秒以上，整個頁面的 INP 評分就會被拉下來。

CrUX 在 2025 到 2026 涵蓋約 1,500 萬個來源網域的真實使用者資料，這份報告也是 Google 用來判定核心 Web 指標的依據，更是搜尋排名訊號的一環。INP 連續兩季紅燈，網站在搜尋結果頁的競爭力就會被同分區的對手吃掉。

主執行緒被卡住的真實樣貌

要理解 INP 為什麼難救，先看主執行緒在做什麼。瀏覽器的主執行緒同時負責 JavaScript 執行、樣式計算、版面重排、繪製與互動處理，一次只能做一件事，所有任務排在同一條時間軸上。當 JavaScript 一段執行超過 50 毫秒，這段任務就被稱為長任務（Long Task），期間任何使用者輸入都只能排隊等候。

把單次互動的延遲拆開，會分成三段。輸入延遲（Input Delay）是使用者按下到事件處理器開始執行之間的等待，這段往往就是主執行緒正在跑其他長任務造成的。處理時間（Processing Duration）是事件處理器本身的執行時間，常見原因是 handler 裡同步做了大量計算或重渲染。呈現延遲（Presentation Delay）是 handler 跑完之後，瀏覽器把畫面更新到螢幕之前的時間，通常與 DOM 節點數量、樣式重新計算的範圍有關。

Chrome 開發者工具的效能面板（Performance Panel）會把這三段直接畫在火焰圖上，按下互動後紅色三角形標記的就是超過 200 毫秒的事件，點進去能看到三段時間的拆分。實際看過幾次就會明白，優化的順序不是先壓縮圖片或上 CDN，而是先把主執行緒上不必要的長任務拔掉。

找出拖慢互動的長任務該看哪些訊號

開始動手調整之前，先把幾個能對應到問題位置的訊號釐清。下面這份清單對應的是 PageSpeed Insights 與開發者工具能直接讀到的數值，每一項都決定該往哪個方向動。

• 長任務時長：任何單一 JavaScript 任務跑超過 50 毫秒就會被歸為長任務，這是主執行緒被佔用的最小單位。理想狀態是把任務拆到 15 毫秒以下，給瀏覽器留出回應輸入的空檔。
• 總阻塞時間（Total Blocking Time，TBT）：頁面載入後到可互動之前，所有長任務超過 50 毫秒的部分加總。實驗數據（Lab Data）中 TBT 偏高，幾乎可以預測現場數據中 INP 也會不過。
• INP 三段拆解：輸入延遲偏高代表主執行緒正被其他任務佔用，處理時間偏高表示事件處理器本身太重，呈現延遲偏高指向 DOM 規模或樣式重算範圍過大。三段對應的解法完全不同，混在一起救只會白費力氣。
• 第三方腳本佔用比例：DevTools Performance 面板有一個 Third Party 過濾選項，能直接看出 Google Tag Manager、客服外掛、廣告碼、推播服務各自佔了多少主執行緒時間。在 WordPress 上這項常常是頭號元兇。
• DOM 節點總數：單頁節點超過 1,500 個就會讓樣式重算與重排成本明顯上升，超過 3,000 個則會把呈現延遲推到危險區。頁面建構器產生的多層巢狀包裝最容易踩到這條線。

數據看過一輪，優先順序大致就出來了。先處理 TBT 與第三方腳本，再處理事件處理器內部的工作量，最後才回頭壓 DOM 與樣式。順序顛倒會發現改了半天，INP 沒動。

把長任務切碎的四種寫法

切分長任務的本質，是讓 JavaScript 在執行過程中主動把控制權交還給瀏覽器，使主執行緒有機會處理排隊中的使用者輸入。下面四個 H3 對應從最古早到最新的解法，技術選型上越後面越優先，但要看相容性決定。

setTimeout 0 的傳統拆法

把一個長迴圈或大型計算拆成多次 setTimeout(fn, 0)，每次只跑一小段，剩下的放回事件佇列。這個寫法跨所有瀏覽器都能用，但有個明顯缺點——放回去的任務會排在所有已存在的任務後面，包含其他第三方腳本注入的工作，實際讓出的時間可能比預期久得多。適合救老舊瀏覽器，新站不建議當主力。

requestIdleCallback 的閒置排程

requestIdleCallback 讓瀏覽器在主執行緒進入閒置狀態時才執行回呼函式，配合 timeRemaining() 可以判斷剩下多少時間能做事。適合分析數據、預先暖機、把不急的工作往後推這類非關鍵任務。Safari 一直支援不完整，跨瀏覽器穩定性要驗過再決定。

scheduler.yield 的繼續優先

Chrome 自 129 版開始正式支援的 scheduler.yield() 是目前最對症的解法。在長任務中間 await scheduler.yield()，函式會暫停並把控制權交回主執行緒。它與 setTimeout 不同的地方在於——這段函式的「續行」（continuation）會被排到所有同類任務的前面，而不是後面。換句話說，主執行緒處理完使用者剛剛的點擊，會優先回來繼續跑你的計算，不會被第三方插入的任務插隊。Safari 與 Firefox 還沒跟上，建議搭 scheduler-polyfill 一起用，跨瀏覽器才一致。

isInputPending 的即時檢查

navigator.scheduling.isInputPending() 可以在迴圈中即時檢查是否有使用者輸入正在等候。回傳 true 就主動跳出當下批次，先讓瀏覽器處理輸入再繼續。適合那些不容易事先切割的計算密集任務，例如資料表格的大批處理。相容性目前限於 Chromium 系，跨瀏覽器要做 polyfill 或退回 scheduler.yield。

WordPress 上常見的主執行緒禍源

WordPress 站台的 INP 問題十之八九不在核心程式碼，而在堆疊上去的擴充功能。下面這份清單對應 PageSpeed Insights 報告中最常標紅的元件，先檢查這幾類就能解掉多數問題。

• 頁面建構器前端 JS：Elementor、Divi、WPBakery 在前台會載入完整的編輯期執行環境，光是初始化就可能吃掉 200 至 400 毫秒。改用區塊主題或啟用建構器的「最佳化前台模式」是根本解。
• 第三方追蹤與客服外掛：Google Tag Manager、Facebook Pixel、線上客服小工具、推播訂閱通知，這類腳本經常在使用者第一次互動的瞬間同步初始化。改用延遲載入或在首次互動後才注入是常見作法。
• 滑動視差與動畫腳本：佈景內建的 AOS（Animate On Scroll）、parallax 套件會在每次捲動觸發版面重算。沒用到就關掉，有用到就限縮觸發範圍。
• 沒有節流的事件處理器：搜尋輸入、即時篩選、滑動更新這類 handler 沒做 debounce 或 throttle，使用者每打一個字就觸發一次完整流程，主執行緒直接卡死。
• 過深的 DOM 結構：頁面建構器愛用巢狀容器包樣式，一個區段套五層 div 是常態。節點數爆量會讓樣式重算的呈現延遲飆升。

外掛數量本身不是問題，問題在每支外掛在前台執行了多少工作。一個寫得好的快取外掛，比五個亂寫的微型外掛更安全。

用 PageSpeed Insights 與 DevTools 實測的順序

wordpress inp 優化不能憑感覺，要有資料對照才知道改動是不是真的有效。建議的實測流程從現場數據出發，再用實驗數據在本地重現問題。

打開 PageSpeed Insights 輸入網址，先看上方的 Core Web Vitals Assessment 區塊。這裡的數字來自 CrUX，是過去 28 天真實使用者的彙整，每天更新一次。INP 顯示為紅色或黃色就代表問題確實存在，不是測試端的偶然波動。記下這個值當基準，之後每次優化完都要回來比對。

切到本地 Chrome 開啟目標頁，按 F12 進入 DevTools，切到 Performance 面板。新版的 Live Metrics 畫面會在右上角即時顯示當下的 LCP、CLS 與 INP，操作頁面時三個數字會跟著跳。如果想用更接近實際使用者的環境測，把 CPU 節流調到 4x 或 6x，模擬中階手機的處理能力。

接著按下錄製，模擬一次完整的使用者互動，例如展開選單、選變化、加入購物車、送出表單。停止錄製後，Interactions 那一軌上紅色三角形就是超過 200 毫秒的事件。點開來能看到輸入延遲、處理時間、呈現延遲三段的拆分，主執行緒底下哪些函式吃掉了時間也一目了然。

第一輪通常會發現一兩個關鍵嫌疑犯，多半是頁面建構器或追蹤碼。逐項處理完再重測，比較 INP 數字有沒有真的降下來。本地數據改善後，現場數據要等 CrUX 滾動平均更新，大約 7 到 28 天才看得到完整效果。

哪些改動對 INP 立竿見影、哪些是長期工

把優化動作按見效時間與成本排序，能避免一頭栽進去最費工的項目卻沒看到成果。下面這張表把常見手段對照起來，便於決定動工順序。

短期能動的，幾乎都是第三方腳本與事件處理器這兩塊。要徹底解掉 INP，多半得回頭檢視主題與建構器的選型。沒有特殊客製需求的站，從區塊主題重新出發，比硬救舊架構合算。

優化沒有一勞永逸，外掛更新、第三方碼變動、流量結構改變，都可能讓 INP 再次惡化。把 PageSpeed Insights 加進每月例行檢查，搭配主機端的真實使用者監測（Real User Monitoring，RUM），才能在掉分的第一週就察覺，而不是等搜尋流量掉下來才回頭找原因。