2024年3月，一個安靜的更新讓無數(shù)技術(shù)團隊連夜加班——INP（Interaction to Next Paint，交互到下一次繪制的時間）正式取代FID（First Input Delay，首次輸入延遲），成為Google衡量網(wǎng)站體驗的核心指標(biāo)。很多人到現(xiàn)在還沒反應(yīng)過來：你的搜索排名，正在被這三個數(shù)字悄悄決定。

低于50分，SEO（搜索引擎優(yōu)化）直接受損；沖到90分以上，排名獲得加權(quán)。這不是建議，是游戲規(guī)則。更麻煩的是，大多數(shù)開發(fā)者嚴(yán)重低估了INP的破壞力——它測量的是用戶點擊按鈕后，到頁面真正響應(yīng)之間的完整延遲，包括事件處理和渲染，比FID嚴(yán)苛得多。

想知道自己站多少分？別信本地測試。

打開pagespeed.web.dev，輸入真實URL。這里同時顯示實驗室數(shù)據(jù)（Lighthouse模擬）和實地數(shù)據(jù)（真實Chrome用戶的訪問記錄）。Google排名用的是后者——你的MacBook Pro跑出來的90分毫無意義，北京用戶用三年前的安卓機加載你的頁面，那才叫數(shù)。

CI里埋雷：讓爛代碼進(jìn)不了主分支

手動測一次容易，持續(xù)守住90分難。把Lighthouse CI（持續(xù)集成工具）焊進(jìn)GitHub Actions（代碼自動化流程），每次提交自動跑分，不達(dá)標(biāo)直接阻斷部署。

配置并不復(fù)雜。在倉庫里新建.lighthouserc.json，把性能門檻寫死：性能總分不得低于0.9，首次內(nèi)容繪制（FCP）控制在2秒內(nèi)，最大內(nèi)容繪制（LCP）2.5秒內(nèi)，累積布局偏移（CLS）小于0.1，總阻塞時間（TBT）壓到300毫秒以下。任何一條紅線被踩，構(gòu)建失敗，代碼回滾。

這套機制的本質(zhì)是：把"事后救火"變成"事前拒止"。團隊再忙，也沒法把爛性能帶到線上。

真實用戶監(jiān)控：知道誰在被傷害

實驗室數(shù)據(jù)是彩排，RUM（Real User Monitoring，真實用戶監(jiān)控）才是現(xiàn)場直播。用web-vitals庫把指標(biāo)埋進(jìn)生產(chǎn)環(huán)境，每次用戶訪問都把CLS、INP、LCP等數(shù)據(jù)回傳到你的分析端。

關(guān)鍵字段包括：指標(biāo)名稱、具體數(shù)值、評級（good/needs-improvement/poor）、變化量（delta）、會話ID、導(dǎo)航類型。keepalive: true確保頁面卸載時也能把數(shù)據(jù)送出去——用戶關(guān)閉標(biāo)簽頁前那半秒的體驗，同樣被記錄。

這套數(shù)據(jù)會告訴你一個殘酷事實：你的P90（90分位）用戶可能正在經(jīng)歷5秒以上的INP，而你的平均值看起來依然健康。優(yōu)化資源該投向誰，數(shù)據(jù)不會撒謊。

LCP優(yōu)化：讓首屏內(nèi)容搶跑

LCP通常是首屏的大圖、標(biāo)題文字或橫幅。瀏覽器要經(jīng)歷"發(fā)現(xiàn)→下載→解碼→渲染"四步，任何一環(huán)卡殼，分?jǐn)?shù)暴跌。

第一步是給關(guān)鍵資源開綠燈。用link rel="preload"提前聲明LCP圖片，fetchpriority="high"告訴瀏覽器這玩意兒優(yōu)先級最高。如果用了響應(yīng)式圖片，把srcset和sizes一并寫進(jìn)preload，否則瀏覽器算不出該下哪個版本，預(yù)加載失效。

圖片格式是另一個戰(zhàn)場。AVIF（AV1圖像文件格式）比WebP再省50%體積，支持漸進(jìn)解碼。用picture標(biāo)簽做降級：瀏覽器支持AVIF就走AVIF，不行換WebP，再不行回退JPEG。ImageMagick或Squoosh都能批量轉(zhuǎn)換，構(gòu)建流程里加一步即可。

但別只顧著壓縮。圖片的原始寬高必須寫在img標(biāo)簽里，否則瀏覽器預(yù)留空間時算錯，布局偏移（CLS）直接起飛。很多設(shè)計師切圖時順手丟個2000×1000的原圖，前端再用CSS縮到800×400——下載量翻6倍，還浪費解碼時間。

字體是LCP的隱形殺手。自定義字體如果用了font-display: swap，文字會先以系統(tǒng)字體閃現(xiàn)，再切到目標(biāo)字體，視覺跳動被計入CLS；如果用block，文字區(qū)域空白直到字體到位，LCP被拖長。最干凈的方案是子集化（只打包用到的字符）+預(yù)加載+可選的font-display: optional——字體3秒內(nèi)到不了，用戶就看系統(tǒng)字體，不再切換。

INP優(yōu)化：把主線程還給人

INP測量的是用戶交互后到下一幀呈現(xiàn)的完整耗時。長任務(wù)（Long Tasks）是罪魁禍?zhǔn)住魏握加弥骶€程超過50毫秒的操作，都會讓點擊、輸入、滾動變得黏滯。

拆解長任務(wù)最直接的方式是yield（讓出）。把同步代碼拆成小塊，用scheduler.yield()或setTimeout(0)把控制權(quán)交還給瀏覽器，讓它有機會處理用戶輸入。React的Time Slicing、Vue的異步更新隊列，底層都是這個邏輯。

事件監(jiān)聽器是另一個重災(zāi)區(qū)。防抖（debounce）和節(jié)流（throttle）能減少執(zhí)行頻率，但更重要的是減少監(jiān)聽器本身的數(shù)量。事件委托把幾十個按鈕的click收攏到父元素，內(nèi)存占用和注冊開銷都大幅下降。

第三方腳本往往是INP的"外包殺手"。聊天插件、分析工具、廣告SDK，經(jīng)常在頁面加載后批量注冊事件、搶占主線程。用Partytown把這些腳本移到Web Worker（瀏覽器后臺線程）里執(zhí)行，DOM操作通過代理轉(zhuǎn)發(fā)，主線程只負(fù)責(zé)渲染。代價是兼容性調(diào)試變復(fù)雜，但對INP的提升是量級差異。

骨架屏和漸進(jìn)式加載能緩解感知延遲，但別把它們當(dāng)遮羞布。真正的優(yōu)化是讓代碼跑得更快，而不是讓用戶看更久的動畫。

CLS優(yōu)化：停止頁面"地震"

CLS測量的是視覺穩(wěn)定性。圖片沒預(yù)留空間、字體突然加載、廣告位動態(tài)插入，都會讓頁面元素亂跳。用戶正要點擊的按鈕突然下移0.5厘米，誤觸和憤怒同時發(fā)生。

所有媒體元素必須帶寬高屬性。響應(yīng)式圖片用aspect-ratio（寬高比）CSS屬性鎖定比例，容器用min-height撐出占位。廣告位如果尺寸不確定，先用占位符占住最小可能高度，實際內(nèi)容加載后只擴不縮。

動畫是CLS的灰色地帶。transform和opacity的變動不計入布局偏移，但width、height、top、left的改動會。把入場動畫從"改變布局"換成"改變繪制層"，視覺效果一樣，分?jǐn)?shù)天差地別。

緩存策略：讓重復(fù)訪問飛起來

首次訪問優(yōu)化到極致，回頭客的體驗同樣重要。Service Worker（服務(wù)工作線程）攔截請求，把靜態(tài)資源緩存到本地，二次加載走本地磁盤，延遲降到毫秒級。

但緩存不是一勞永逸。版本更新時，舊資源必須及時淘汰。Workbox的緩存策略分幾種：Stale-While-Revalidate（先返回緩存，后臺更新）、Cache-First（優(yōu)先緩存，沒有才網(wǎng)絡(luò)）、Network-First（優(yōu)先網(wǎng)絡(luò)，失敗回退緩存）。靜態(tài)資源用Stale-While-Revalidate，HTML入口用Network-First，平衡速度和新鮮度。

CDN（內(nèi)容分發(fā)網(wǎng)絡(luò)）的邊緣緩存是另一層加速。把LCP圖片、關(guān)鍵CSS推到離用戶最近的節(jié)點，TTL（生存時間）根據(jù)更新頻率設(shè)定。版本號打在文件名里，更新即換URL，緩存永不過期問題。

2026年的新戰(zhàn)場：INP的精細(xì)化治理

INP取代FID已滿兩年，但多數(shù)團隊的優(yōu)化仍停留在"減少長任務(wù)"的粗粒度階段。下一步是建立交互熱力圖：哪些按鈕被點擊最多？哪些輸入框觸發(fā)最頻繁的重新計算？RUM數(shù)據(jù)按元素維度聚合，找出真正的瓶頸點。

輸入延遲（Input Delay）和處理延遲（Processing Delay）在INP中各占多少比例？前者說明主線程繁忙，需要yield；后者說明事件回調(diào)太重，需要優(yōu)化算法或拆異步。用PerformanceObserver（性能觀察器）在客戶端拆解這兩個階段，針對性下藥。

框架層面的優(yōu)化也在進(jìn)化。React 18的并發(fā)特性、Vue 3的響應(yīng)式重構(gòu)、Svelte的編譯時優(yōu)化，都在減少主線程負(fù)擔(dān)。但框架救不了爛代碼——一個同步的1000次循環(huán)，在任何框架里都是長任務(wù)。