INP 互動至下一次繪製
2024 已取代 FID，長任務是主因
INP 像按服務鈴到店員回應的時間——鈴按了沒反應，客人不會想「它在處理」，只會再按十下然後生氣。
03為什麼是現在學
INP（互動至下一次繪製）2024 年取代 FID 成為正式指標，門檻 200ms。它抓的是「整個瀏覽過程中最卡的那次互動」——比舊指標誠實得多。
04白話理解（對客戶簡報可直接引用）
INP 量使用者每次點擊/輸入後畫面多快有反應。主因幾乎都是「主執行緒被長任務卡住」：太肥的 JS、第三方追蹤碼、一次處理太多資料的事件處理器。修法：砍第三方腳本（每個追蹤碼都在偷 INP）、長任務切塊、重運算移出主執行緒。
05工具箱
- ▸PSI 實地資料的 INP — p75 才算數
- ▸DevTools Performance 的 Long Tasks — 抓出 >50ms 的兇手
06怎麼做 · SOP 3 步（每步標產出物）
- 1確認 INP 現況與最差互動情境→ INP 基準
- 2第三方腳本清點：不用的移除、必要的延後載入→ 第三方治理紀錄（見 t19）
- 3長任務切塊/防抖→ 程式修復紀錄
07場景應用（實戰經驗）
- ◆GTM 裡累積九個行銷像素的站，INP 380ms——清到三個必要像素後降到 170ms。誰偷了 INP，清單攤開就知道。
08⚠️ 常見誤區
- ✕只在自己的高階電腦測——INP 的災情在中低階手機，實地資料才反映真實。
口訣
「每個追蹤碼都在偷 INP；長任務切塊還。」
10里程碑 · 完成標準（可驗證）
- ☐行動版 INP p75 ≤ 200ms
- ☐第三方腳本有清單與理由
學習者勾自己的進度；顧問勾客戶專案的交付——同一份標準，兩種用法。
12檢核方式與依據出處
程式自動判定：輸入網址，掃描引擎自己爬、自己打 API、自己判定。
- 🟢 官方明文web.dev：INP 定義與優化 ↗
依據等級決定計分權重（🟢×3／🔵×2／⚠️×1）——權重量的是「依據有多硬」， 不是「我們覺得多重要」。查無權威文件的判準，誠實標「業界慣例」。