TL;DR：INP 是 Core Web Vitals 用來衡量「使用者操作後，畫面多久有反應」的互動速度指標；實務上，網站不只要載入快，也要讓點擊、選單、表單與篩選互動在真實裝置上保持順手。要改善 INP，重點不是盲目壓圖片，而是找出慢互動、拆掉 JavaScript 長任務、降低重繪成本，並用真實使用者資料持續驗證。
INP（Interaction to Next Paint）是 Core Web Vitals 中衡量網頁互動回應速度的指標，觀察使用者點擊、輕觸與鍵盤操作後，到瀏覽器能繪製下一個畫面的延遲時間，主要用於評估真實使用者互動是否順暢。
我在做 SEO 網站與客製化互動網站時，常看到一個誤會：網站首頁 Lighthouse 分數看起來不差，但使用者真的點開選單、切換方案、送出表單或展開 FAQ 時，畫面卻卡一下。這類問題過去不一定會被 FID 明確反映，但現在會進入 INP 的觀察範圍，也會直接影響使用者對網站「專業度」與「可信任感」的感受。
為什麼 INP 會取代 FID？
INP 取代 FID 的原因，是 FID 只觀察第一次輸入延遲，而 INP 會觀察整個頁面生命週期中的點擊、輕觸與鍵盤互動，更接近使用者真正感受到的互動順暢度。
根據 Google Search Central 的 INP 導入公告，INP 在 2024 年 3 月正式取代 FID 成為 Core Web Vitals 的互動性指標。換句話說，網站不再只需要處理「第一次點擊會不會卡」，而是要處理整趟瀏覽過程中每個重要互動是否穩定。
FID 與 INP 的差異可以這樣看：
表格整理：比較項目｜FID｜INP；衡量範圍｜使用者第一次互動的輸入延遲｜整個頁面期間多次互動的延遲表現；關注重點｜瀏覽器何時開始處理事件｜從互動開始到下一次畫面更新完成；常見盲點｜第一次互動正常，後面仍可能很卡｜更容易看見選單、篩選、表單、購物車等慢互動；對網站製作的提醒｜初始 JS 不要阻塞太久｜每個重要互動都要有可感知的回饋速度
我通常會把 FID 想成「開門第一下有沒有卡」，而 INP 更像「整間店逛起來順不順」。對需要 SEO、品牌信任與轉換的網站來說，後者更接近真實商業結果。
INP 分數怎麼判讀？
INP 的良好門檻是 200 毫秒以內，超過 200 毫秒到 500 毫秒代表需要改善，超過 500 毫秒通常會被視為不佳互動體驗。
web.dev 的 INP 官方說明 提到，INP 會觀察使用者與頁面互動時的延遲，並以頁面中最慢的互動作為主要判斷依據；對互動次數較多的頁面，系統會排除少數離群值，避免單一極端事件過度扭曲結果。Google Search Central 的 Core Web Vitals 文件 也將 INP 小於 200 毫秒列為良好體驗門檻。
在實務判讀上，我會把 INP 分成三段來看：
- 輸入延遲（Input delay）：使用者點擊後，瀏覽器主執行緒是否還被其他工作卡住。
- 處理時間（Processing duration）：事件處理函式本身做了多少 JavaScript 工作。
- 顯示延遲（Presentation delay）：事件處理完後，瀏覽器完成樣式計算、版面配置、繪製與合成需要多久。
這也是為什麼很多網站明明圖片已經壓縮、主機也不慢，INP 卻仍然不好。問題往往藏在過重的前端狀態更新、第三方腳本、複雜 DOM、一次改太多元素，或互動後觸發了昂貴的 layout/re-render。
如何找出拖慢 INP 的互動？
找 INP 問題時，應該先看真實使用者資料，再回到開發工具定位是哪個互動、哪段任務與哪個畫面更新造成延遲。
第一步可以先用 Google Search Console 的 Core Web Vitals 報表 或 PageSpeed Insights 了解整體頁面群組是否有 INP 問題。這類資料偏向 field data，能反映真實使用者裝置、網路與瀏覽情境，比只看自己電腦上的測試更可靠。
接著可以用 web.dev 的 field data 診斷指南 往下追慢互動來源。若網站有工程資源，我會建議使用 web-vitals attribution build 或瀏覽器 Performance API，把慢互動發生在哪個元素、哪個事件類型、哪個頁面情境記錄下來。
如果要更技術一點，可以搭配 MDN PerformanceEventTiming 文件 理解 Event Timing API 如何回報互動延遲；另外，若懷疑主執行緒被長任務阻塞，也可以參考 MDN PerformanceLongTaskTiming 文件，觀察超過 50 毫秒的長任務。
我自己的診斷順序通常是：
- 先看頁面群組：哪些模板或路徑 INP 最差，例如首頁、商品列表、服務頁、案例頁。
- 找互動元素：慢互動是選單、篩選器、輪播、表單、購物車，還是彈窗。
- 拆成三段延遲：判斷是事件排隊太久、JS 處理太重，還是畫面更新太貴。
- 比對裝置差異：手機端通常比桌機更容易暴露 INP 問題。
- 回到真實數據驗證：不要只修到本機 DevTools 變順，要看 field data 是否回收。
這個流程比「猜是哪個套件慢」可靠很多，也比較符合 E-E-A-T 內容該有的工程判斷：先定義問題，再定位證據，最後才修。
如何實作 INP 優化？
INP 優化的核心是減少主執行緒在互動當下的負擔，讓瀏覽器能更快處理事件並完成下一次畫面更新。
web.dev 的 INP 優化指南 建議開發者減少 event callback 中的工作量、把非必要工作延後、拆分長任務，並降低 rendering work 的成本。這些建議放到網站製作實務中，可以整理成一套比較好落地的檢查表。
做法一：把事件處理函式變短
互動當下不要一次做太多事。像是點擊按鈕後同時做資料整理、埋點、DOM 更新、動畫啟動、第三方事件、狀態同步，很容易把一個小互動變成長任務。
比較好的做法是先完成使用者看得見的回饋，再把非視覺必要的工作延後：
- 點擊後先更新按鈕狀態或顯示 loading。
- 分析事件、次要資料處理、非必要 API 呼叫可以延後。
- 大量清單排序或篩選不要卡在同一個同步任務裡。
做法二：拆長任務，讓瀏覽器有機會喘氣
當 JavaScript 長時間佔用主執行緒，瀏覽器就沒辦法即時回應下一個互動。這也是很多網站「看起來已經載入完成，點起來卻慢」的主因。
可以評估以下做法：
- 把大型同步運算切成小批次。
- 使用合適的排程方式，把不急的工作延後到互動回饋之後。
- 避免在使用者點擊當下才初始化大型套件。
- 第三方腳本能延遲就延遲，能移除就移除。
做法三：降低互動後的畫面重繪成本
有些 INP 問題不是 JS 函式本身太慢，而是事件結束後造成太多 layout、style recalculation 或 paint。常見情境包含大型選單展開、FAQ 全部重算高度、篩選商品後整頁重排、React/Vue 狀態更新範圍過大。
我會特別檢查：
- 是否一次改動太多 DOM 節點。
- 是否在互動後同步讀寫 layout 屬性造成 forced reflow。
- 是否能縮小元件 re-render 範圍。
- 是否能用 CSS 控制簡單狀態，而不是全部交給 JavaScript。
- 對非可視區內容，是否能用 content-visibility 或延遲渲染策略降低成本。
做法四：保留互動回饋，不要只追分數
INP 優化不是把動畫全部砍掉，也不是讓網站變得無聊。真正的目標是讓使用者操作後馬上知道「系統有收到」，再逐步完成較重的工作。
例如沉浸式網站或高互動品牌頁，仍然可以有精緻動畫，但應避免在點擊當下才觸發大量模型、材質、腳本初始化。比較穩的做法是提前載入必要資源、縮小互動當下的工作量，並用輕量回饋先接住使用者感受。
哪些網站最容易踩到 INP 問題？
INP 問題最常出現在互動很多、第三方腳本多、前端狀態複雜或手機使用者比例高的網站。
以下幾種網站我會特別提早檢查：
表格整理：網站類型｜容易卡住的互動｜常見原因｜優先改善方向；企業形象網站｜漢堡選單、FAQ、聯絡表單｜動畫與第三方追蹤腳本疊加｜減少互動當下 JS、先給即時回饋；電商網站｜商品篩選、加入購物車、規格切換｜清單重排與狀態更新範圍太大｜虛擬化清單、縮小 re-render、拆任務；內容型網站｜目錄跳轉、分享按鈕、留言區｜廣告、分析與嵌入元件過多｜延遲第三方腳本、降低主執行緒壓力；沉浸式網站｜場景切換、互動動畫、滑動控制｜WebGL 或動畫初始化太晚｜預載關鍵資源、互動前先準備；SaaS / 後台｜表格篩選、搜尋、批次操作｜大量資料同步處理｜批次處理、延遲非必要運算
對台灣中小企業網站來說，我最常看到的是「功能不多，但外掛很多」。一個表單工具、一個聊天插件、一組行銷追蹤、一個輪播套件，看起來都不大，但全部疊在一起就會讓互動變慢。
INP 優化可以怎麼排進網站製作流程？
INP 不應該等網站上線後才補救，而應該在設計、開發與驗收階段就被納入效能預算。
我會建議用這個流程處理：
- 設計階段先定義重要互動：選單、CTA、表單、篩選、購物車、動態區塊，都先列入檢查清單。
- 開發階段避免互動當下才做重工作：能預載、能拆分、能延後的工作，不要全部塞在點擊瞬間。
- 元件階段控制 re-render 範圍：React、Next.js、Vue 專案都要注意狀態更新是否牽動過大區域。
- 測試階段用慢速手機思維驗收：不要只用高階 MacBook 看動畫順不順。
- 上線後看 field data：用 Search Console、PageSpeed Insights 或自建 RUM 觀察真實使用者資料。
這也是我在橋序創研做 SEO 網站時很重視的一點：效能不是工程師炫技，而是內容能不能被閱讀、CTA 能不能被點擊、表單能不能被順利送出的基礎。
FAQ
INP 會直接影響 SEO 排名嗎？
Core Web Vitals 是 Google 搜尋體驗訊號的一部分，但 SEO 排名不會只看 INP。比較實際的理解是：INP 改善能讓使用者互動更順，降低卡頓與放棄行為，間接提高內容閱讀、CTA 點擊與轉換品質。
INP 和網站載入速度是一樣的嗎？
不一樣。載入速度常看 LCP 等指標，而 INP 看的是使用者互動後到下一次畫面更新的延遲；所以一個網站可以載入很快，但點擊選單或表單時仍然很卡。
只用 Lighthouse 測 INP 夠嗎？
不夠。Lighthouse 可以幫助找實驗室環境下的效能線索，但 INP 更需要真實使用者資料，因為不同裝置、網路、瀏覽器與互動行為都會影響結果。
WordPress 網站也需要在意 INP 嗎？
需要。WordPress 網站常因外掛、佈景主題、第三方追蹤碼與頁面建構器累積太多前端工作，導致互動延遲變高；如果網站依賴表單、選單、彈窗或電商功能，就更應該檢查 INP。
INP 優化一定要改程式碼嗎？
不一定。有些問題可以透過移除不必要外掛、延遲第三方腳本、減少頁面元件或調整動畫解決；但若問題來自前端架構、狀態管理或大量 DOM 更新，通常就需要工程層級調整。
把互動速度變成網站轉換的一部分
INP 的重點不是把網站做成只剩文字，而是讓每一次互動都更像「有被接住」。使用者點擊 CTA、展開服務方案、填寫表單、切換作品案例時，如果畫面能快速回應，網站的信任感就會自然提高。
如果你的網站已經有內容與流量，卻在表單、CTA 或關鍵互動上轉換不穩，橋序創研可以協助你從 SEO 網站架構、Core Web Vitals 效能檢查、沉浸式互動設計到 AI 自動化資料回收，一起把「看得到」的流量變成「操作得順」的商業結果。