我們打開 Chrome DevTools，跑一個 Lighthouse，
一堆Web英文縮寫撲面而來：
-
LCP 紅了？
-
FID 沒過？
-
CLS 啥意思？
-
還有個什么 TTFB？
它們到底在測什么指標？又該怎么優(yōu)化？
別急，這篇文章就是為了解決這些“字母恐懼癥”。
我們將用前端視角 + 用戶視角，帶你逐個搞懂 Web 性能的核心指標。
它們是 Core Web Vitals（核心網(wǎng)頁指標）的一部分，由 Google 推出，目標是：
用真實用戶體驗角度，衡量網(wǎng)頁的加載速度、交互響應(yīng)和視覺穩(wěn)定性。
而且它們不是簡單的“跑分”，是真的會影響 Google SEO 排名和產(chǎn)品體驗的關(guān)鍵指標。
|
指標 |
含義 |
用戶感知 |
推薦值 |
|---|---|---|---|
|
FCP (First Contentful Paint) |
首次繪制內(nèi)容 |
頁面開始有東西了 |
< 1.8s |
|
LCP (Largest Contentful Paint) |
最大內(nèi)容繪制完成 |
主要內(nèi)容加載完成 |
< 2.5s |
|
FID (First Input Delay) |
首次交互延遲 |
點了頁面多久有反應(yīng) |
< 100ms |
|
CLS (Cumulative Layout Shift) |
累積布局偏移 |
頁面是不是亂跳 |
< 0.1 |
|
TTFB (Time to First Byte) |
首字節(jié)時間 |
后端響應(yīng)速度 |
< 0.5s |
-
觸發(fā)點：頁面中第一個非白屏內(nèi)容（如文本、圖片、SVG）出現(xiàn)時
-
用戶感知：頁面開始加載啦
-
提前加載關(guān)鍵 CSS
-
減少 JS 阻塞渲染
-
使用服務(wù)器渲染，預渲染輸出基礎(chǔ)結(jié)構(gòu)
-
通常是頁面的主圖、主標題、大模塊
-
Chrome 會判斷“最大可見塊”，不是你決定的！
-
關(guān)鍵圖片/標題提前加載（preload）
-
使用現(xiàn)代圖片格式（WebP/AVIF）
-
避免慢 JS 阻塞渲染流程
-
例如：點按鈕、點擊搜索框、按 Tab 等
-
用戶會覺得“卡”，通常是 JS 主線程被鎖了
-
減少首次加載 JS 數(shù)量
-
拆分包、懶加載
-
使用 requestIdleCallback 等異步技術(shù)延遲非關(guān)鍵邏輯
-
頁面加載時元素跳來跳去？按鈕滑走？廣告插入？頁面先裸奔一下？這就是 CLS 高
-
Google 超討厭這個，用戶也會煩
-
圖片、視頻標簽必須設(shè)置寬高占位
-
避免動態(tài)內(nèi)容插入頭部
-
使用動畫過渡代替強插入
-
瀏覽器點擊鏈接后，多久拿到服務(wù)器第一個響應(yīng)字節(jié)
-
后端慢、DNS 慢、CDN 沒命中，都會拉高這個指標
-
開啟緩存
-
使用 CDN 靠近用戶
-
后端響應(yīng)路徑盡可能精簡
-
使用 Chrome DevTools → Performance → Lighthouse
-
使用 Chrome 插件：Web Vitals、Core Web Vitals Reporter
-
引入 web-vitals JS 庫，上報到埋點系統(tǒng)
import { getLCP, getFID, getCLS } from 'web-vitals';
getLCP(console.log);
getFID(console.log);
getCLS(console.log);
性能不只是“加載速度”，而是從打開頁面到點下按鈕的 完整體驗過程。
通過這五個指標，你可以更有目的地優(yōu)化每一步：
-
FCP → 讓用戶知道“頁面來了”
-
LCP → 讓用戶覺得“主內(nèi)容出來了”
-
FID → 讓用戶一操作就有反應(yīng)
-
CLS → 別讓用戶追著按鈕跑
-
TTFB → 別讓后端拖累前端。
本文地址: http://miniball.cn/google-seo-chrome-lighthouse-core-web-vitals-fcp-lcp-fid-cls-ttfb.html
