INP 與 FID：Google 改用 INP 為核心指標的原因

不少人曾在 PageSpeed Insights 看著 FID 亮綠燈，便以為網站的互動體驗沒有問題。Google 在 2024 年用 INP 取代 FID，不是因為 FID「量錯」，而是它僅涵蓋第一次互動的輸入延遲，無法反映事件處理與下一次畫面更新。依 web.dev 的 INP 說明文件，INP（Interaction to Next Paint，互動至下一個繪製）補上了這些限制。

一句話講完整篇：FID 量的是「互動發生後，瀏覽器多久開始處理」，INP 量到事件處理完成並呈現下一個畫面的時間。INP 不包含伺服器回應，也不涵蓋畫面更新之後才完成的非同步工作。

如果你是網站主、行銷人或工程師，若你曾經被 PageSpeed Insights 或 Search Console 跳出來的 INP 紅字嚇到、卻不確定它跟以前那個 FID 到底差在哪裡，這篇就是寫給你的。我不會丟一堆效能術語給你，而是用白話把「Google 為什麼換、換了什麼、你該怎麼辦」這三件事講到底。讀完，你會知道自己的網站到底有沒有被 INP 卡到，也知道下一步該從哪裡動手，更不會再把 FID 跟 INP 這兩個名字混為一談。

先講結論：FID 量到的，從來不是使用者真正在乎的事

我先把結論擺前面，方便你決定要不要往下讀。

Core Web Vitals（核心網頁體驗指標，簡稱 CWV）是 Google 用來衡量「使用者在網頁上感覺到的體驗」的一組量化指標，目前有三個：LCP 量載入、CLS 量視覺穩定、INP 量互動流暢度（定義見 web.dev 的 Core Web Vitals 說明）。在 2024 年 3 月之前，第三個位置坐的是 FID，現在換成了 INP。這不是改名字，是換了一個測量邏輯完全不同的新指標。

兩者最大的差別在這張表，先記住它，後面的所有細節都是從這裡展開的：

比較項目	FID（已淘汰）	INP（現役）
量的是什麼	首次輸入的「延遲」（瀏覽器多久才開始處理）	每一次互動到畫面更新的「完整時間」
涵蓋範圍	僅有頁面生命週期內的第一個合格互動	追蹤整次瀏覽的合格互動，依互動數量取接近最慢的高百分位值
是否包含處理與繪製	不包含，僅量「輸入延遲」這一小段	包含，從輸入延遲、處理時間到繪製延遲全包
及格門檻	100 毫秒	200 毫秒
淘汰／上線時間	2024 年 3 月退役	2024 年 3 月正式上線

你會發現一件弔詭的事：INP 的及格門檻（200 毫秒）比 FID（100 毫秒）還寬鬆。這不是 Google 放水，而是兩個指標量的東西根本不能直接比較。FID 僅量一小段，所以標準自然訂得嚴；INP 量的是完整歷程，標準就得用另一把尺。這個細節我在第六段會再解釋清楚。

FID 到底量了什麼？拆解一個被淘汰的指標

要懂 Google 為什麼換掉 FID，得先搞清楚 FID 到底量了什麼，又漏了什麼。

當使用者對一個網頁做出「互動」（點擊、輕觸、按鍵）時，從他手指落下到畫面真的出現變化，中間其實經歷了三個階段：

• 輸入延遲（Input Delay）：從使用者點下去，到瀏覽器開始執行事件處理器之間的空檔。這段時間通常是因為主執行緒被其他工作（多半是 JavaScript）占住，瀏覽器還沒空理會這次輸入。
• 處理時間（Processing Time）：事件處理器實際執行的時間，也就是你的 JavaScript 程式碼跑完要多久。
• 繪製延遲（Presentation Delay）：事件處理器跑完之後，到瀏覽器把更新後的畫面畫出來之間的等待。

FID 量到的，僅有第一段。它記錄的是「使用者點下去，到瀏覽器終於開始處理」這之間的延遲，後面兩段它完全不管（對照 web.dev 對 INP 的定義）。

可以把它想成按下電梯按鈕：FID 量的是系統多久開始處理按鈕事件，INP 則量到介面下一次顯示回饋。電梯真正抵達樓層的時間屬於後續非同步工作，兩個指標都不一定完整涵蓋。

換個角度想，FID 當年被設計成僅量「輸入延遲」，其實有它的時代背景。在 2020 年 Core Web Vitals 剛推出時，網頁常見的體驗問題之一是「頁面看起來載完了、但一點就卡住」，原因可能是載入階段大量的 JavaScript 占用主執行緒，使用者點下去時，瀏覽器還無法開始處理輸入。FID 抓的就是這段等待時間。不過，事件處理與畫面更新也會造成使用者感受到的延遲，FID 的測量範圍並未涵蓋，因此改用 INP 評估整段互動延遲。

還有一個更致命的限制：FID 僅記錄頁面上的第一個互動。第一下點擊之後，不論使用者再點幾百次、畫面卡成什麼樣子，FID 都不再更新。換句話說，FID 等於僅用「開場第一秒的表現」來評斷整支球隊，後面九十分鐘完全不採計。

INP 換了一個完全不同的測量邏輯：從「第一次點擊」到「每一次互動」

INP 的設計邏輯，幾乎是衝著 FID 的每一個盲點來的。

當使用者跟頁面互動時，INP 會把前述那三個階段（輸入延遲、處理時間、繪製延遲）全部加起來，得到「這次互動到畫面出現下一幀」的完整時間。這個完整時間，才是使用者主觀感受的「卡不卡」（見 web.dev 對 INP 的定義）。

而且 INP 不是僅看第一次。它在整個頁面生命週期裡，會追蹤使用者的每一次互動（點擊、輕觸、鍵盤輸入都算），然後取其中最差的一個（嚴格說是接近最差的高百分位數值）作為這個頁面的 INP 分數。

這兩個差異疊起來，意義非常清楚：

• FID 僅看第一個合格互動，INP 觀察整次瀏覽並取接近最慢的互動。
• FID 僅看頭，INP 從頭看到尾。
• FID 僅量開始處理前的等待，INP 量到下一次畫面更新。

你大概開始明白 Google 為什麼非換不可了。一個僅用「開場第一秒、而且僅看按鈕亮起來的速度」來評分的指標，跟使用者實際體驗的差距實在太大。

一個會讓你秒懂的場景

假設你網站的首頁有一個「加入購物車」的按鈕。使用者在頁面剛載入時不小心點了空白處（觸發了 FID，0 毫秒，完美），接著點「加入購物車」，畫面卡了 1.2 秒才反應。在 FID 的世界裡，這個頁面是滿分；在 INP 的世界裡，這個頁面被記上 1200 毫秒，直接掉到「差」的等級。

哪一個分數，比較接近使用者的真實感受？答案很明顯。這就是 Google 把 FID 換成 INP 的核心理由：抓到使用者真正抱怨的那些互動。

Google 為什麼非換不可：FID 留下的三個盲點

如果要用更結構化的方式講，FID 有三個互相疊加的盲點，任何一個都足以讓它失去作為「互動體驗指標」的資格。

盲點一：僅採計第一個互動。現代網頁的互動大多發生在頁面載入完成之後很久。滾動到一半點選單、看完商品描述按規格切換、填表時按送出鈕，這些才是使用者真正會卡到的地方。FID 對這些場景完全失明。一個網站可以設計成「第一次點擊反應飛快、後續每一次點擊都卡半秒」，FID 還是給它綠燈。

盲點二：僅量輸入延遲，不量處理與繪製。很多卡頓其實出在事件處理器本身跑太久，或繪製階段被龐大的 DOM 拖累。這些都是使用者會罵的問題，但 FID 一個都量不到。結果就是 FID 分數漂亮的網站，使用者體驗可以爛到不行。

盲點三：分數區分力有限。因為 FID 僅量第一個互動的輸入延遲，許多頁面即使後續互動卡頓仍可能得到良好分數。這是採用 INP 的重要理由之一。

INP 正好把這三個洞補上：採計所有互動、量完整歷程、而且分數分布更貼近真實體驗。這不是錦上添花，是從根上換掉了測量邏輯（見 web.dev 對 INP 的說明）。

從 FID 到 INP 的時間軸：一場長達四年的換崗實驗

很多人以為 INP 是 Google 某天突然丟出來的新東西。其實這個換崗動作整整鋪陳了四年，過程是公開且可查證的。我把關鍵時間點整理出來，讓你對這件事的來龍去脈有底。

1. 2020 年：Core Web Vitals 正式上線，三個指標是 LCP、FID、CLS。FID 從這時候開始擔任「互動體驗」的把關角色（見 web.dev 的 Core Web Vitals 說明）。
2. 2022 年：web.dev 發表 INP 的實驗性介紹，公開承認 FID 有不足之處，並開始蒐集真實使用者的互動資料，看看 INP 這個新邏輯能不能更準地反映體驗。
3. 2023 年：Google 官方宣布，INP 將在隔年正式取代 FID，成為 Core Web Vitals 的第三個指標。這等於給了整個網站生態將近一年的緩衝期去調整。
4. 2024 年 3 月：INP 正式成為穩定的 Core Web Vitals 指標，FID 同步退役。從這一天起，Google 用來衡量互動體驗的，就是 INP，不再是 FID（見 web.dev 的 INP 說明）。

Google 以 INP 取代 FID，表示它更適合作為核心互動指標；這不表示 FID 在每一個測量維度都毫無診斷價值，而是 INP 的涵蓋範圍更完整。

老實說，看到一個指標從實驗、宣布、到正式上線花四年，我反而比較安心。這代表 Google 不是拍腦袋決定，而是用大量真實資料去驗證過的。對我們做網站的人來說，跟著一個有資料支撐的指標走，比跟著一個憑感覺訂出來的指標走，踏實多了。

INP 的及格線怎麼算：200 與 500 這兩個數字的邏輯

搞懂了為什麼換，接下來要搞懂的是：INP 多少才算及格？這個問題我每次被問到，都會先把門檻數字講清楚，因為數字本身就是 INP 設計哲學的具體化。

web.dev 為 INP 訂了三個等級：良好為小於或等於 200 毫秒；需要改善為大於 200、且小於或等於 500 毫秒；差為超過 500 毫秒。

等級	INP 數值	使用者的主觀感受
良好	≤ 200 毫秒	幾乎感覺不到延遲，覺得「很順」
需要改善	> 200 且 ≤ 500 毫秒	互動回饋較慢，值得找出常見瓶頸
差	> 500 毫秒	明顯覺得「卡住了」，會想關掉頁面

這裡要分兩層看：單次頁面瀏覽的 INP 會從該次瀏覽的互動中取接近最慢的值；判斷網站是否達到 Core Web Vitals 門檻時，則看真實瀏覽資料的第 75 百分位，並分開評估行動與桌機。兩個百分位概念不能混成同一個計算。

門檻制定同時考量高品質體驗與現有裝置能力，並透過真實資料評估可達性；依 web.dev 對門檻制定方式的說明，200 毫秒不是所有人「開始明顯有感」的生理定律，也不能與 FID 的 100 毫秒直接換算。

翻成白話就是：Google 真正在意的，是多數使用者裡體驗較差的那四分之一有沒有被照顧到，平均值的數字再好看也不是它的焦點。這是一個從平均思維走向長尾思維的指標設計，我個人很認同這個方向。

講白了，這個 p75 的設計對中小網站是友善的。它不要求你的每一次互動都快，只要求你把「多數使用者裡偏慢的那一群」照顧好。換句話說，就算有少數使用者在極端網路或老舊裝置上體驗很差，若那群人沒有佔到總訪客的四分之一，你的 INP 還是有機會拿到綠燈。這給了我們一個很明確的優化優先順序：先處理「會被大量使用者踩到、而且反應慢」的那幾個互動，不必追求每一次點擊都完美。資源有限的時候，把力氣花在影響面最大的瓶頸上，報酬率最高。

INP 會讓我的排名掉下來嗎？CWV 與排名的真實關係

這一段是我最常被問的問題，也是很多人把 INP 當成「排名炸彈」的誤解來源。我要把話講直一點。

Core Web Vitals 本來就是 Google 排名因素的一部分，這件事從 2021 年就是公開資訊。更早的源頭可以追溯到 2018 年，Google 當時就預告行動搜尋會把網頁速度納入考量（〈Using page speed in mobile search〉，2018 年 1 月）。到了 CWV 正式上線後，LCP、FID（現在是 INP）、CLS 這三個指標，就成了 Google 評估「網頁體驗」這個排名維度的量化依據。

CWV 是 Google 頁面體驗訊號的一部分，但相關性與內容品質通常更重要。Google 沒有把它定義成固定的「平手裁判」公式，也沒有公布權重；把 INP 壓低不會保證排名上升。

所以誠實的說法是這樣：

• INP 很差代表真實使用者常遇到慢回饋，值得修正；無法從單一指標預測排名幅度。
• 從需要改善降到良好，可能改善互動體驗與轉換流程，但停留時間、跳出率及排名變化仍需實測，不能串成必然因果。
• 把 INP 當成唯一的排名救命稻草，是搞錯了重點。它跟跳出率與 SEO 的關係一樣，是「整體體驗拼圖」的一塊，不是單獨的魔法開關。

CWV 現場資料來自符合條件的 Chrome 使用者，Search Console 會分開呈現行動與桌機網址群組。行動優先索引不等於僅採用行動版 CWV 排名；優化時仍應依實際受眾與兩種報表檢查。

追求好的 INP，主要回報是讓操作更順暢，降低使用者在關鍵互動時受阻的機會。Core Web Vitals 也是 Google 頁面體驗訊號的一部分，但相關性與內容品質仍然重要，不應把 INP 改善換算成固定排名增幅。關於速度為什麼對使用者很重要，web.dev 的〈Why does speed matter?〉有很直白的整理，有興趣可以對照著看。

怎麼量 INP：現場資料與實驗室資料的差別

知道目標在哪裡之後，下一步是搞清楚怎麼量。INP 的量測分兩種，搞混的話你會對著錯誤的數字白忙一場。

哪些互動會被 INP 計入、哪些不會

要量 INP，你得先搞清楚「互動」的定義。INP 僅計入三種使用者輸入：點擊（click）、輕觸（tap）、鍵盤按鍵（keydown），定義見 web.dev 的 INP 文件。這三種動作的共同點是：它們都會觸發 JavaScript 事件處理器，瀏覽器需要安排主執行緒去回應。INP 量的，就是「瀏覽器從收到這個輸入，到畫面給出下一幀更新」的完整時間。

反過來說，有兩類動作 INP 完全不計入：純粹的滾動（scrolling）與滑鼠的懸停（hover）。滾動在瀏覽器內部是走另一條合成器執行緒（compositor thread），不經過主執行緒的事件佇列，所以它不在 INP 的計分範圍裡；滑鼠移過某個元素觸發的 hover 狀態，同樣不算互動。這個區分很重要，因為很多網站的「滾動卡頓」其實不會反映在 INP 上，它反映在另一個維度，你拿 INP 去診斷滾動問題會找錯方向。

還有一個容易忘記的細節：INP 計的是「一個互動」，而一個互動可能由好幾個事件組成。例如一次點擊會依序觸發 pointerdown、mousedown、pointerup、mouseup、click 這一連串事件，INP 會把這整串算成「一次互動」，記錄的是從第一個事件到畫面更新的最長時間。所以你不需要去擔心「我同一個元素綁了五個 click handler 會不會被記五次」，INP 看的是使用者感受到的「這一下點擊」的整體回應速度。

第一種是現場資料（Field Data），也就是真實使用者在你的網站上互動時，瀏覽器回傳的實測資料。這份資料最貼近真實體驗，因為它來自各種裝置、各種網路環境、各種真實的操作行為。Google 排名用的就是這份。Google Search Console 的 Core Web Vitals 報表，就是這份現場資料的彙整，它會直接告訴你哪些網址的 INP 落在哪個等級。

第二種是實驗室資料（Lab Data），是在受控環境下測量。PageSpeed Insights 會同時顯示可用的 CrUX 現場資料與 Lighthouse 實驗室資料；Lighthouse 沒有真實使用者互動，因此不直接產生 INP，通常用 TBT 等指標協助診斷主執行緒阻塞。

比較項目	現場資料（Field）	實驗室資料（Lab）
來源	真實使用者瀏覽器回傳	受控環境的模擬測試
Google 排名是否採用	是	否（但可作為優化依據）
代表性	高，涵蓋各種裝置與網路	受限於測試腳本與環境
適合用來	看整體健康度、找出有問題的頁面群	重現問題、逐一除錯
代表工具	Search Console CWV 報表、CrUX	PageSpeed Insights、Lighthouse、WebPageTest

我的實務習慣是兩者搭配用：先用 Search Console 的 CWV 報表看整體，找出 INP 橘燈或紅燈的那批網址；再用 PageSpeed Insights 或 Lighthouse 針對單一頁面跑實驗室測試，把問題重現出來除錯。這兩份資料的分工很清楚，現場資料告訴你「哪裡有問題」，實驗室資料幫你「把問題拆開來看」。

現場資料源頭是 Chrome 使用者體驗報告（CrUX）。Search Console 與 PageSpeed Insights 的現場數字都使用 CrUX，通常反映最近 28 天的滾動視窗，且需要足夠樣本；新頁或低流量頁可能沒有網址層級資料。剛改完隔天看不到明顯變化很正常，但不必等固定「滿一個月」才有意義。

如果你還沒開始用 Search Console，先把GSC 的基本功能摸熟，CWV 報表是裡面最被低估的一塊，很多網站問題它都比你的直覺早一步指出來。想知道有哪些免費工具可以幫你測速度，也可以參考這篇網站速度測試工具的整理。

PageSpeed Insights 若有足夠 CrUX 樣本，會顯示現場 INP；Lighthouse 實驗室區塊不會提供真正的 INP，常見的是 TBT 等診斷指標。兩者用途不同，不能把 TBT 綠燈當成現場 INP 已通過。

把 INP 降下來：拆解 Long Task，把主執行緒還給使用者

量完之後才動手改善。INP 常見瓶頸包括主執行緒上的長 JavaScript 任務、昂貴的樣式計算與版面配置，以及過大的 DOM。

回想前面講的 INP 三個階段（輸入延遲、處理時間、繪製延遲），幾乎都跟主執行緒能不能空出來有關。當一段 JavaScript 工作跑得太久、超過 50 毫秒，它就被稱為 Long Task（長任務）。Long Task 進行的這段時間，主執行緒被占住，使用者的任何互動都得排隊等它跑完，INP 就這樣被拖上去（見 web.dev 的 Optimize long tasks）。

所以降 INP 的主軸，其實就是「減少並拆碎 Long Task，讓主執行緒隨時有空回應使用者」。具體可以從這幾個方向下手：

• 拆碎長任務。把一個跑很久的同步工作，切成很多個小段，每段之間用瀏覽器提供的 yield 機制（例如 setTimeout、scheduler.yield() 或 requestIdleCallback）把主執行緒交還給瀏覽器，讓它有機會處理使用者的互動（作法整理於 web.dev 的長任務優化說明）。
• 把非必要的 JavaScript 延後載入。很多網站的問題源頭很單純：一開始就載了一堆用不到的程式碼（追蹤碼、廣告腳本、用不到的套件），主執行緒還沒開始工作就被占滿。把這些用延遲載入的方式推到頁面可互動之後再執行，主執行緒一開始就輕得多。
• 審查第三方腳本。第三方腳本（分析、廣告、聊天外掛、A/B 測試工具）是 INP 的隱形殺手。它們往往不歸你管，卻會在你的主執行緒上大肆占用時間。定期盤點，把用不到的拿掉、把可以延後的延後。
• 減少主執行緒的工作量。這包括：拆分過大的 JavaScript bundle、移除沒在用的相依套件、避免在事件處理器裡跑重運算（例如同步的資料排序或大量 DOM 操作）。JavaScript 的渲染與執行成本，可以進一步看JavaScript SEO的相關討論。
• 改善繪製階段。龐大的 DOM、過多的樣式計算、複雜的動畫，都會讓繪製延遲這一段變長。保持 DOM 結構精簡、避免強制同步版面配置（layout thrashing），對 INP 的第三段有直接幫助。

這裡再給你一個分辨問題出在哪一段的訣竅。如果你在 DevTools 看到 INP 的組成裡，輸入延遲那一段特別長，代表主執行緒在你點下去之前就被別的工作占住了，你要修的是「誰在搶主執行緒」（通常是背景的 JavaScript、廣告腳本、或同步的第三方 SDK）。如果長的是處理時間，代表你的事件處理器本身跑太慢，要修的是你的程式邏輯（拆工作、簡化運算、避免在事件裡做重活）。如果長的是繪製延遲，問題出在畫面更新太吃力，通常是 DOM 太大或樣式太複雜。先搞清楚慢在哪一段，再對症下藥，才不會白改一輪。

這裡我給你一個我自己常用的快速診斷法：打開 Chrome 的開發者工具（F12），到 Performance（效能）面板錄製一段操作，然後看時間軸上有沒有一大片橘黃色的「Task」橫條。那一大塊就是卡住主執行緒的 Long Task，橘黃色的長度就是你的互動被延遲的時間。看一眼，大概就知道問題出在哪一段 JavaScript（對照 web.dev 的 Optimize long tasks）。

把長任務拆開：yield 的具體長相

前面講「拆碎長任務」，我把它再講具體一點，免得你僅知道方向、不知道怎麼動手。所謂 yield（讓出主執行緒），就是在一段長工作的中間，插一個「把控制權還給瀏覽器」的空檔，讓瀏覽器趁這個空檔處理使用者剛剛送進來的互動。

歷史最久的做法是用 setTimeout 把工作往後推一個 tick，這招相容性最高，缺點是它讓出的時間不可控。較新的瀏覽器提供了 scheduler.yield()，這是專為拆任務設計的 API，讓出的時機更精準、延續性也更好。對於真的不急的工作，requestIdleCallback 可以把它排到瀏覽器真的有空閒時再做。這三個工具的核心精神是同一個：不要讓一段 JavaScript 工作連續霸佔主執行緒超過 50 毫秒（見 web.dev 的長任務優化說明）。

實務上我會建議你從一個問題開始問自己：「這段工作，真的需要在使用者點下去的那一刻就同步跑完嗎？」很多時候答案是不需要。能搬到背景跑的、能切成好幾段慢慢跑的、能等到頁面閒下來再跑的，就讓出主執行緒。這個思考習慣一旦建立起來，你會發現降 INP 的真正功課，其實是「區分哪些工作是必要的同步、哪些是可以讓的」。

INP 不及格時，長任務、過重的 JavaScript、複雜 DOM 與第三方程式碼都是常見排查方向，但不能未量測就認定原因。先在 DevTools Performance 或實際使用者監測資料找出慢互動，再決定要拆分工作、延後非必要程式、簡化繪製，或調整事件處理。

順帶一提，LCP（載入）跟 CLS（視覺穩定）這兩個 CWV 夥伴，跟 INP 的優化方向常常是疊加的。把 JavaScript 減量、把資源延後載入，通常 LCP 也會跟著變好，CLS 因為畫面跳動變少也會改善。想一次看懂三個指標的關係與優化重點，可以接著讀Core Web Vitals 完全攻略，或是入門性質的CWV 白話文介紹。LCP 與 CLS 的官方定義我也附上，方便你對照：web.dev 的 LCP 說明與CLS 說明。

而如果你要的是把整體載入速度拉起來的系統性做法（快取、CDN、資源壓縮等），我們整理的速度指南跟快取設定教學會更對你的胃口，這兩塊跟 INP 是互補關係，不是二選一。

關於 INP，我常被問到的三個誤解

帶網站做 INP 健檢幾年下來，我發現大家對這個指標有幾個反覆出現的誤解。把它們講破，你才不會把力氣花錯地方。

誤解一：INP 紅燈，等於我的網站整個爛掉了。並非如此。INP 衡量的是「互動的回應速度」，它是一個面向的分數，不是網站總成績。一個內容紮實、產品優秀的網站，完全可以同時擁有紅燈的 INP 與高轉換率。INP 紅燈真正告訴你的是「某幾個互動慢得讓使用者有感」，你要做的是把那幾個互動找出來修掉；打掉重練整個網站，是最不划算的選擇。把它當成體檢報告裡的一項紅字、一個需要追蹤處理的單一項目，別把它讀成整份判決書。

誤解二：開發機測起來很順，所以 INP 沒問題。現場資料涵蓋不同裝置與環境，確實可能和高速桌機差很多；但不能宣稱絕大多數樣本都是中階手機。應分別看 Search Console 的行動與桌機報表，再以自有 RUM 資料找出實際受影響的裝置與互動。

誤解三：把 INP 壓到綠燈，流量就會進來。INP 是排名的「加分題」訊號，性質上屬於打破平手的依據，前提是你跟對手的內容實力要相近。如果你的內容本身比對手弱、關鍵字佈局比對手散，把 INP 修到 50 毫秒也不會讓你反超。INP 修好之後，你會先看到的是「使用者停留變長、轉換動作完成率提高」，這些才是它真正的回報；流量是這些改善長期累積下來的結果，不是一拉開關就湧入的東西。想把這層因果關係跟更廣的 SEO 全貌接起來，可以回頭看這篇SEO 基礎入門，把指標放回整體策略裡看。

一張行動清單：從今天開始的 INP 健檢六步

底下是一份今天就能開始的六步清單，用來建立網站 INP 的基準與回測流程。

1. 第一步：用 Search Console 看現場資料。打開 GSC 的 Core Web Vitals 報表，看你網站有沒有 INP 橘燈或紅燈的網址群。這份報表告訴你「問題在哪裡、多嚴重」，是起點也是基準。
2. 第二步：用 PageSpeed Insights 跑單一頁面。查看可用的現場 INP，再用 Lighthouse 的 TBT、主執行緒與長任務診斷線索重現問題；實驗室區塊不會提供真正的 INP。
3. 第三步：到開發者工具找 Long Task。用 Performance 面板錄一段會卡頓的操作，找時間軸上那幾塊橘黃色的 Task。它們就是你要動刀的地方（判讀方式見 web.dev 的 Optimize long tasks）。
4. 第四步：盤點 JavaScript 與第三方腳本。把頁面上的第三方追蹤碼、廣告腳本、聊天外掛列一輪，問自己「這個真的需要嗎？需要，能不能延後到頁面可互動之後再載入？」多數網站的 INP 問題，答案藏在這個盤點裡。
5. 第五步：拆碎長任務、延後非必要資源。把同步的長工作切成小段並適時 yield；把非必要的腳本用延遲載入往後推。這一步是降 INP 的主戰場。
6. 第六步：持續回測。先用自有 RUM 觀察新版本，再等待 CrUX 最近 28 天的滾動資料逐步反映變更；不要把它誤解成每月僅更新一次。

這六步的重點是建立一個「量、找、修、回測」的循環，一次做到完美從來不是目標。INP 也不是改一次就定型的數字，它會跟著你網站每一次的功能擴充、每一次外掛更新而變化。把它當成需要持續關注的健康指標；它是一場長期維護，補考一次就過關從來不切實際。

不要把 INP 當成單獨的 技術性 SEO 考題，要把它放回使用者體驗。釋放主執行緒可能讓按鈕與表單回饋更即時，是否改善轉換則要透過資料驗證。

INP 取代 FID，本質上是 Google 終於願意用「使用者真正感受到的體驗」來衡量網站。對認真做網站的人來說，這是好事，因為它獎勵的是那些把使用者放在心上的人。把主執行緒還給使用者、把每一次互動都當一回事，這就是 INP 想要你做到的，也是我一直相信的網站經營之道。Google 換了一個更誠實的尺，剩下的，就看我們願不願意跟著把體驗做紮實。從今天起，先把 Search Console 打開，看看你的 INP 是哪一種顏色，那就是最好的起點。