页面没挂，用户却觉得越来越慢：用 sitespeed.io 把 Web 性能回归卡在发版前

功能回归最容易漏掉一种失败：按钮能点、接口返回 200、页面也没有报错，但首屏比上个版本慢了，布局不断跳动，点击之后半天没有反馈。单次手工打开页面很难证明退化来自本次 PR，开发者本机的“挺快”也不能成为发版依据。sitespeed.io 的价值不是再做一张性能大盘，而是把同一 URL、同一浏览器、同一轮次的证据固定下来，让性能退化像功能断言一样被复查。

先说结论：这不是再加一个大盘

先用 Docker 对一个公开或测试页面跑 5 次，保留中位数、HTML 报告、HAR 和视频，再讨论 CI 门禁。性能数据天然有噪声，不要用单次 LCP 或总分直接卡发布；QA 要固定网络、机器、页面状态和采样轮次，并把预算放在用户真正感知的指标上。

**对应的 QA 工作：**Web UI 性能回归与发布门禁。

**AI 具体参与哪一步：**这不是 AI 工具；它用真实浏览器采集性能指标、视频、HAR 和 CPU 长任务，适合做确定性的质量基线。

QA 当天真正面对的任务

不用工具时，通常要做这些动作：

• 手工打开页面凭体感判断快慢
• 从浏览器 DevTools 临时截一张瀑布图
• 发现线上变慢后再回查多个版本
• 把接口耗时、资源体积和主线程阻塞混在一起讨论
• 每次复测都缺少相同环境与相同轮次

问题不只是“步骤多”，而是证据没有统一结构。不同人会按不同顺序翻日志、选指标、判断相似性；当结果需要复查时，团队只能重新走一遍过程。更合理的目标不是让工具替 QA 下结论，而是让输入、处理规则、失败分支和最终产物可以重复。

工具到底接管哪一段

从官方资料可以确认的能力是：

• 官方仓库说明它会驱动 Chrome、Firefox、Edge 或 Safari 等真实浏览器
• 报告可包含 Core Web Vitals、页面加载视频、HAR 瀑布、Coach 建议和 CPU 长任务分析
• 官方建议真实测量运行多轮并看中位数，单次结果存在噪声
• 可用于一次性诊断、CI 性能回归和持续监控

这里要区分“官方支持”和“基于能力推导”。本文只把官方明确描述的能力写成事实；把它用于上述 QA 场景，是一条验证方案，不代表已经在所有团队证明有效，也不编造节省比例、成功率或运行结果。

最小验证：不要先接全量生产链路

按下面顺序做一个 10 至 30 分钟的小验证；若工具本身需要平台部署，则先完成输入输出评估，不承诺十分钟落地。

1. 选一个登录前页面或可稳定准备状态的测试页面
2. 用官方 Docker 命令运行，先确认结果目录、浏览器和页面能够正常加载
3. 把轮次改为 5，固定浏览器并记录测试机器、网络和缓存策略
4. 查看 LCP、INP、CLS、TTFB、资源瀑布和长任务，不只看一个综合分数
5. 选一个已知稳定版本作为参考，再给关键指标设置有容忍区间的预算

可从官方说明中的命令开始：

docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io https://www.example.com

# 本地安装后，固定 Chrome 并运行 5 轮
sitespeed.io https://www.example.com --browser chrome -n 5

QA 要验收的不是“工具跑完了”

至少保留以下检查：

• 页面是否真正加载到业务完成状态，而不是只测到骨架屏
• 第三方资源、广告或埋点是否让结果不可重复
• 缓存冷启动与热启动是否分开记录
• 性能预算是否使用多轮统计而不是单点值
• 失败报告能否定位到资源、请求或长任务证据

建议把产物拆成三层：第一层是原始输入和版本，例如包哈希、页面 URL、模型版本、工作流 run id；第二层是工具生成的结构化结果；第三层是 QA 的人工判定和理由。三层不能互相覆盖，否则下一次回归无法区分“输入变了”“工具判断变了”还是“人工标准变了”。

故意制造失败，才能知道它是否可用

最小验证不能只跑 Happy Path，至少覆盖：

• LCP 变慢但接口耗时正常
• CLS 增大导致页面跳动
• 主线程长任务让点击迟迟不响应
• 第三方脚本抖动制造假回归

对于 AI 或基于历史推荐的能力，还要增加一条反证：准备一个看起来相似但根因不同的样本，检查系统是否过度合并；准备一个没有历史答案的新问题，检查它是否愿意输出“不确定”并升级人工。能停手、能保留未知，通常比强行给结论更重要。

提效点要按少做了什么来算

这套方案理论上减少的是：

• 少做凭体感反复刷新页面
• 一次产出指标、视频、瀑布和建议四类证据
• PR 前后结果可以按同一口径比较
• 开发定位时直接查看慢资源和长任务，而不是重新复现

这些收益来自流程动作减少，并非本文实测出来的百分比。后续真要评估，应记录同一批任务在两种方式下的人工步骤数、需要打开的系统数量、未知问题数量、返工次数和最终证据完整度，不只统计“执行耗时”。

什么时候不该用

• 共享 CI 机器和公网网络会放大噪声，需要稳定执行环境
• 实验室数据不能代表全部真实用户设备与网络
• 性能预算需要业务基线，不能照搬别人的阈值
• 登录态、个性化页面和复杂前置数据需要额外脚本

Lighthouse 适合快速审计单页，浏览器 DevTools 适合人工深挖一次问题；sitespeed.io 更适合可重复运行、保留多类证据并接入 CI。若目标是线上真实用户体验，还需要配合 RUM 数据，不能只靠实验室测试。

不可替代的人工判断包括：业务影响、风险接受、规则阈值、误报处理、数据合规和最终发布决定。工具可以生成候选、归集证据或执行确定性检查，但不能承担质量责任。

最后的判断

值得验证的标准不是“功能很多”，而是它能否把一项真实 QA 任务变成可重复、可复查、可拒绝的流程。建议先用一个小对象验证输入、失败分支和产物，再决定是否接 CI、部署平台或扩大权限。只要最小场景无法留下完整证据，就不要被仪表盘、Agent 或自动修复能力带着走。

官方资料

• https://github.com/sitespeedio/sitespeed.io
• https://www.sitespeed.io/documentation/