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