前言¶
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。
