Speed Monitoring 技能的目的是提供持续性能监控的模式，以防止速度回归并维持 Core Web Vitals 得分。它通过建立自动化测试、真实用户监控与告警系统，在性能问题影响用户之前发现它们。
核心规则包括：预算先于构建，在 budget.json 中预先设定性能预算；监控真实用户，实验室数据不等同于现场数据，需同时跟踪合成数据与 RUM；对回归进行告警，用基于阈值的告警在用户之前发现问题；阻断不良部署，通过 Lighthouse CI 在性能回归时使 CI 失败；长期跟踪，趋势比快照更重要，需存储历史数据；衡量 Core Web Vitals，在生产环境测量 LCP、CLS、INP、FCP、TTFB；自动化测试，在每次 PR 和主分支推送时运行 Lighthouse CI；包大小限制，在 CI 流水线中强制执行 JS/CSS 预算；真实用户数据，使用 web-vitals 库加 beacon API 获取现场数据；仪表盘可见性，让性能指标对团队可访问。
性能预算目标：LCP 良好 <2.5s、警告 2.5–4s、严重 >4s；FCP 良好 <1.8s、警告 1.8–3s、严重 >3s；CLS 良好 <0.1、警告 0.1–0.25、严重 >0.25；INP 良好 <200ms、警告 200–500ms、严重 >500ms；TBT 良好 <200ms、警告 200–600ms、严重 >600ms。资源预算（gzip）：JavaScript 200KB、CSS 50KB、图片 500KB、字体 100KB、总计 800KB。
监控栈分为合成（实验室数据）与真实用户（现场数据）。合成侧包括 GitHub Actions 中的 Lighthouse CI、用于生产监控的定时 cron 任务、CI/CD 流水线中的预算断言。真实用户侧包括用于 Core Web Vitals 的 web-vitals 库、用于页面指标的 Navigation Timing API、用于资源分析的 Resource Timing API、用于可靠数据传输的 sendBeacon。告警渠道包括用于警告的 Slack webhook、用于关键性能问题的 PagerDuty、用于周报的邮件摘要。
实施清单涵盖初始设置（创建 budget.json、添加 lighthouserc.json、设置 Lighthouse CI GitHub Action、配置性能断言最低分 90）、真实用户监控（安装 web-vitals 包、客户端实现 vitals 跟踪、创建 /api/vitals 端点、设置指标存储数据库）、包监控（创建 bundle-stats.js 脚本、在 CI 添加包大小检查、设置 gzip 大小预算）、告警（配置 Slack webhook、设置性能阈值、在 API 实现告警逻辑、测试告警通知）、仪表盘（创建性能仪表盘页面、显示当前 Core Web Vitals、展示历史趋势、添加预算状态指示器）。
参考主题包括性能预算、Lighthouse CI、Web Vitals 监控、性能告警、合成监控。禁止事项：生产环境无性能监控、忽略现场数据（RUM）、无 CI 性能检查、未定义性能预算、仅手动运行 Lighthouse、屏蔽性能告警。完成定义要求：性能预算已定义并文档化、Lighthouse CI 在 GitHub Actions 中运行、CI 在性能回归（分数 <90）时失败、生产环境跟踪 Web Vitals、CI 中监控包大小、为差分数配置告警、安排每周性能审查、团队可访问性能仪表盘。具体配置代码、脚本内容与版本信息暂未提供。