前言¶
Core Web Vitals（CWV）是 Google 用來衡量頁面體驗的三項指標：LCP（最大內容繪製）、INP（交互到下一次繪製）和 CLS（累積佈局偏移）。搜索排名與頁面體驗信號會參考這些指標，且按 第 75 百分位（p75） 評估——即約 75% 的訪問需達到「良好」閾值。
日常排障裏，Lighthouse 或 PageSpeed Insights 往往能指出「哪項指標不合格」，卻很少直接對應到「哪一個 DOM 元素、哪段資源或哪行代碼」。通用性能建議也容易泛泛而談。下面介紹 core-web-vitals Skill：它把三項 CWV 拆成可執行的診斷與修復路徑，並強調先量後改、用現場數據定優先級、用瀏覽器 trace 找根因。
這是什麼¶
core-web-vitals 是 web-quality-skills 倉庫中的 Agent Skill（metadata 標註作者爲 web-quality-skills，版本 2.0，MIT 許可）。一句話定位：結合 現場（field） 與 實驗室（lab） 證據，針對 LCP、INP、CLS 做定向優化。
官方 description 寫明適用場景包括：被要求「improve Core Web Vitals」「fix LCP」「reduce CLS」「optimize INP」「page experience optimization」或「fix layout shifts」時使用。在 officialskills.sh 上的說明還提到：覆蓋圖片預加載、主線程優化、佈局偏移防護，以及用 web-vitals 庫做現場測量；並包含面向 Next.js、React、Vue 的模式（以 Skill 文檔爲準）。
維護與歸屬：Skill 文件位於 Addy Osmani 的 web-quality-skills 倉庫路徑 skills/core-web-vitals；安裝入口見下文。
三項指標與閾值¶
Skill 文檔用表格固定了「良好 / 需改進 / 差」的邊界（與 Google 公開口徑一致）：
| 指標 | 衡量內容 | 良好 | 需改進 | 差 |
|---|---|---|---|---|
| LCP | 加載 | ≤ 2.5s | 2.5s – 4s | > 4s |
| INP | 交互響應 | ≤ 200ms | 200ms – 500ms | > 500ms |
| CLS | 視覺穩定 | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
優化前應先確認當前是 哪一項 在 p75 上未達標，再只深入該項相關的洞察與代碼，避免「全站泛泛加緩存」卻碰不到真正的 LCP 元素或 CLS 觸發源。
核心功能¶
先測量，再優化¶
有可訪問 URL 時，Skill 要求優先閱讀同倉庫下的性能測量流程（../performance/references/MEASUREMENT.md），並建議順序爲：
- 查看頁面級 CrUX p75；若無頁面級數據，使用明確標註的 origin 回退。
- 在聲明的條件下錄製 瀏覽器性能 trace；配合 Chrome DevTools MCP 時，trace 摘要可一併帶上 CrUX 與本次 lab 指標。
- 只分析失敗指標相關 的 insights，再檢查牽涉的代碼與資源。
- 修復後 用等價的 lab 測量重跑；不要聲稱現場指標會立刻變好——CrUX 與一方 RUM 需要新的用戶訪問纔會更新。
若僅有源碼、沒有運行時證據，Skill 允許推斷可能原因，但 不得 在無證據時斷言 LCP、INP 或 CLS 一定不合格。
LCP：常見問題與檢查清單¶
LCP 度量最大可見內容元素完成繪製的時間，常見 LCP 元素包括首屏大圖/視頻、大段文字、背景圖或 <svg>。
文檔歸納的典型問題包括：TTFB 過高（> 800ms）、渲染阻塞 CSS/JS、LCP 資源發現過晚、客戶端渲染導致內容晚於 JS 纔出現，以及通過 Speculation Rules API 做可測量的「下一跳」導航優化（文檔強調不能替代修復當前頁 LCP，且需注意帶寬、副作用與 Chromium 限定）。
Skill 內附 LCP optimization checklist（TTFB、可發現性與 fetchpriority、圖片格式與尺寸、關鍵 CSS、字體 font-display、SSR/SSG、Speculation Rules 等），以及用 PerformanceObserver 在當前會話中定位 LCP 元素的調試片段（屬於單次 lab，非現場數據）。
INP 與 CLS：引用專項文檔¶
- INP：要求把輸入延遲、處理時間、呈現延遲分開看；現場 INP 差或 trace 顯示慢交互時，閱讀 Skill 內
references/INP.md（trace 解讀、長任務、第三方與渲染原因、單會話 observer、一方歸因等）。 - CLS：強調用現場歸因或 trace 找到 位移節點與觸發器，不要假設「肉眼看到的受害者」就是根因；現場 CLS 差時閱讀
references/CLS.md（預留空間、動態內容、字體與動畫、調試 observer、驗證清單）。
測量來源與邊界¶
| 來源 | 用途 |
|---|---|
瀏覽器性能 trace（Chrome DevTools MCP：performance_start_trace） |
單次加載或交互診斷；可用附帶的 CrUX 上下文 |
| CrUX 或 Search Console | 聚合真實用戶 p75，定優先級 |
| Lighthouse CLI 或 PageSpeed Insights | 無 DevTools 時的受控 lab 回退 |
| 一方 RUM | 按路由、設備、版本等切分線上體驗 |
原生 PerformanceObserver |
調試單次會話 |
文檔明確：不要 用 Chrome DevTools MCP 的 lighthouse_audit 走性能（該能力面向非性能類 Lighthouse 類別）；不要 把單次 lab 數值與現場 p75 當作同一總體直接對比。
安裝與啓用¶
官方在 officialskills.sh 給出的安裝方式爲：
npx skills add https://github.com/addyosmani/web-quality-skills --skill core-web-vitals
也可將 Skill 目錄鏈接交給編碼助手安裝：
https://github.com/addyosmani/web-quality-skills/tree/main/skills/core-web-vitals
Skill 本體爲通用 SKILL.md 格式；Cursor、Codex CLI、Claude Code 等具體 UI 差異以各產品當前對 npx skills add 或粘貼倉庫路徑的支持爲準，本文不展開未在官方頁覈實到的配置項。
典型用法（來自官方說明的可復現場景）¶
下列場景摘自 officialskills.sh 的 When to use it，與 Skill 文檔方向一致，可作爲對話入口示例：
- 用
fetchpriority等方式預加載 hero 圖，把 LCP 壓到 2.5s 以內。 - 將長數組處理拆塊，避免點擊處理函數長時間阻塞主線程（改善 INP）。
- 爲商品圖補
width/height，減少縮略圖網格跳動（CLS）。 - 在廣告位注入前預留
min-height，避免廣告網絡異步插入導致佈局偏移。 - 接入 web-vitals 庫並寫入 Google Analytics，跟蹤 p75 相關現場指標。
修復 LCP 時，文檔中的 HTML/JS 對比示例說明了：關鍵 CSS 內聯、非關鍵樣式延遲、preload + fetchpriority="high" 僅在與 trace 證明「發現過晚」時使用，以及用 SSR/SSG 替代純客戶端拉數渲染首屏內容。
適用場景與注意¶
適合誰：需要把 CWV 從「報表上的紅字」落到具體改動的前端與全棧開發者；已有 CrUX、Search Console 或一方 RUM，希望 Agent 按 Skill 流程先看 p75、再看 trace 的團隊。
限制與坑：
- 無運行時證據時不要下結論；現場改善需要新訪問週期，修完只能先驗證 lab 等價測量。
- Speculation Rules、部分 DevTools MCP 能力依賴 Chromium 生態；Safari/Firefox 行爲以各瀏覽器文檔爲準。
- INP/CLS 的深入步驟在 Skill 引用的
INP.md、CLS.md中，需與主 SKILL.md 一起使用。 - 與同倉庫的 web-quality-audit（更廣的 Lighthouse 向審計）相比，本 Skill 專項 於 CWV 三項，路徑更短、更易在對話裏復現「指標 → 模式 → 補丁」的鏈條——這也是其相對通用性能建議更易被團隊傳播的原因之一（傳播效果本身未在官方資料中量化，此處僅爲工作方式對比）。
結尾¶
core-web-vitals 把 Google 公開的三項 Core Web Vitals 閾值、測量順序和 LCP/INP/CLS 的分工寫進 Agent 可遵循的 SKILL.md，並對接 CrUX、trace 與框架側常見反模式。若你正在處理搜索與體驗信號相關的性能工單，可從官方倉庫安裝並在對話中直接引用指標名稱或 URL。
