我們打開 Chrome DevTools，跑一個(gè) Lighthouse，

一堆Web英文縮寫撲面而來(lái)：

• LCP 紅了？

• FID 沒過？

• CLS 啥意思？

• 還有個(gè)什么 TTFB？

它們到底在測(cè)什么指標(biāo)？又該怎么優(yōu)化？

別急，這篇文章就是為了解決這些“字母恐懼癥”。

我們將用前端視角 + 用戶視角，帶你逐個(gè)搞懂 Web 性能的核心指標(biāo)。

它們是 Core Web Vitals（核心網(wǎng)頁(yè)指標(biāo)）的一部分，由 Google 推出，目標(biāo)是：

用真實(shí)用戶體驗(yàn)角度，衡量網(wǎng)頁(yè)的加載速度、交互響應(yīng)和視覺穩(wěn)定性。

而且它們不是簡(jiǎn)單的“跑分”，是真的會(huì)影響 Google SEO 排名和產(chǎn)品體驗(yàn)的關(guān)鍵指標(biāo)。

• 觸發(fā)點(diǎn)：頁(yè)面中第一個(gè)非白屏內(nèi)容（如文本、圖片、SVG）出現(xiàn)時(shí)

• 用戶感知：頁(yè)面開始加載啦

• 提前加載關(guān)鍵 CSS

• 減少 JS 阻塞渲染

• 使用服務(wù)器渲染，預(yù)渲染輸出基礎(chǔ)結(jié)構(gòu)

• 通常是頁(yè)面的主圖、主標(biāo)題、大模塊

• Chrome 會(huì)判斷“最大可見塊”，不是你決定的！

• 關(guān)鍵圖片/標(biāo)題提前加載（preload）

• 使用現(xiàn)代圖片格式（WebP/AVIF）

• 避免慢 JS 阻塞渲染流程

• 例如：點(diǎn)按鈕、點(diǎn)擊搜索框、按 Tab 等

• 用戶會(huì)覺得“卡”，通常是 JS 主線程被鎖了

• 減少首次加載 JS 數(shù)量

• 拆分包、懶加載

• 使用 requestIdleCallback 等異步技術(shù)延遲非關(guān)鍵邏輯

• 頁(yè)面加載時(shí)元素跳來(lái)跳去？按鈕滑走？廣告插入？頁(yè)面先裸奔一下？這就是 CLS 高

• Google 超討厭這個(gè)，用戶也會(huì)煩

• 圖片、視頻標(biāo)簽必須設(shè)置寬高占位

• 避免動(dòng)態(tài)內(nèi)容插入頭部

• 使用動(dòng)畫過渡代替強(qiáng)插入

• 瀏覽器點(diǎn)擊鏈接后，多久拿到服務(wù)器第一個(gè)響應(yīng)字節(jié)

• 后端慢、DNS 慢、CDN 沒命中，都會(huì)拉高這個(gè)指標(biāo)

• 開啟緩存

• 使用 CDN 靠近用戶

• 后端響應(yīng)路徑盡可能精簡(jiǎn)

• 使用 Chrome DevTools → Performance → Lighthouse

• 使用 Chrome 插件：Web Vitals、Core Web Vitals Reporter

• 引入 web-vitals JS 庫(kù)，上報(bào)到埋點(diǎn)系統(tǒng)

import { getLCP, getFID, getCLS } from 'web-vitals';
getLCP(console.log);
getFID(console.log);
getCLS(console.log);

性能不只是“加載速度”，而是從打開頁(yè)面到點(diǎn)下按鈕的 完整體驗(yàn)過程。

通過這五個(gè)指標(biāo)，你可以更有目的地優(yōu)化每一步：

• FCP → 讓用戶知道“頁(yè)面來(lái)了”

• LCP → 讓用戶覺得“主內(nèi)容出來(lái)了”

• FID → 讓用戶一操作就有反應(yīng)

• CLS → 別讓用戶追著按鈕跑

• TTFB → 別讓后端拖累前端。

本文地址: http://m.naizhaoqj.cn/google-seo-chrome-lighthouse-core-web-vitals-fcp-lcp-fid-cls-ttfb.html