Google把網站排名和這3個數字掛鉤，90分以下直接降級

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

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

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

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

CI里埋雷：讓爛代碼進不了主分支

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

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

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

真實用戶監控：知道誰在被傷害

實驗室數據是彩排，RUM（Real User Monitoring，真實用戶監控）才是現場直播。用web-vitals庫把指標埋進生產環境，每次用戶訪問都把CLS、INP、LCP等數據回傳到你的分析端。

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

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

LCP優化：讓首屏內容搶跑

LCP通常是首屏的大圖、標題文字或橫幅。瀏覽器要經歷"發現→下載→解碼→渲染"四步，任何一環卡殼，分數暴跌。

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

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

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

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

INP優化：把主線程還給人

INP測量的是用戶交互后到下一幀呈現的完整耗時。長任務（Long Tasks）是罪魁禍首——任何占用主線程超過50毫秒的操作，都會讓點擊、輸入、滾動變得黏滯。

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

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

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

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

CLS優化：停止頁面"地震"

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

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

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

緩存策略：讓重復訪問飛起來

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

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

CDN（內容分發網絡）的邊緣緩存是另一層加速。把LCP圖片、關鍵CSS推到離用戶最近的節點，TTL（生存時間）根據更新頻率設定。版本號打在文件名里，更新即換URL，緩存永不過期問題。

2026年的新戰場：INP的精細化治理

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

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

框架層面的優化也在進化。React 18的并發特性、Vue 3的響應式重構、Svelte的編譯時優化，都在減少主線程負擔。但框架救不了爛代碼——一個同步的1000次循環，在任何框架里都是長任務。