Core/Dash CI/CD 自动性能检查

只需一次 curl 调用即可将 Core/Dash 集成到你的 CI/CD 流水线。在上线前标记超出性能预算的构建。追踪每次部署的真实用户性能。

免费试用

Trusted by market leaders · Client results

哪次部署让页面变慢了？

两个月前你的 LCP 是 2.1 秒。现在是 2.9 秒。期间你部署了四十次。问题在于：光看时间线无法告诉你哪次部署导致了变慢。

coredash release tracking

因此 Core/Dash 将每个真实用户的每次访问与特定部署匹配起来。我们认为 RUM 数据应该告诉你“v2.4.1 导致了这个问题”，而不是“上个月某个东西变慢了”。

Core/Dash 在每次部署前后运行两项检查。部署前，Core/Dash 扫描你的预览构建。如果页面超出预算，它会标记流水线。部署后，每个页面浏览都会被打上部署版本标签，因此每个版本都会根据自身的真实用户流量进行衡量。

这两项检查在不同时间点捕获 Core Web Vitals 问题。部署前检查是合成测试，所以它能发现构建本身存在的错误：新的首屏图片是 4MB 的 PNG，营销标签在打包产物中添加了 300KB 的脚本。部署后检查是纯 RUM 数据。这确切告诉你一次发布对 LCP、INP 和 CLS 的实际影响。

1：部署前：合成测试

Core/Dash 可以扫描受监控页面的样本。扫描结果会与你自己的 Core/Dash 性能预算进行对比。如果页面超标，你会在部署前收到通知。收到通知后如何处理由你决定。

为了保证检查客观，Core/Dash 只对同一个构建在两次运行间不会变化的内容进行评分。Lighthouse 性能分数在两次测试同一页面时，可能会有十分的波动。因为它受 CPU 耗时影响很大，而且运行审计的机器不可能两次完全相同。如果在 CI 中对它评分，你会得到毫无意义的红色流水线。

将检查添加到你的 CI/CD 流水线

首先创建一个项目 API 密钥（在应用中：你的项目，然后 AI Insights，然后 Connect Your AI）。然后将这一步添加到你的部署任务前。它调用检查接口，耗时约 30 到 45 秒。

STATUS=$(curl -sS -o gate.json -w '%{http_code}' -X POST "https://app.coredash.app/api/project/releases/check" \
  -H "Authorization: Bearer $COREDASH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"tag":"v1.2.3","origin":"https://preview.example.app"}')

if [ "$STATUS" != "200" ]; then
  echo "CoreDash check failed to run (HTTP $STATUS): $(cat gate.json)" >&2
  exit 0
fi

VERDICT=$(jq -r '.data.check.status' gate.json)
echo "CoreDash: $VERDICT"

# if [ "$VERDICT" = "breach" ]; then exit 1; fi   ## 取消注释以阻止部署

默认情况下，这只会将结果报告到你的 CI 日志中。当页面超出预算时，取消最后一行注释以使构建失败。

数据 Schema：

字段	必填	描述
`tag`	是	你的版本字符串。字母、数字、`.` `_` `/` `-`，最多 64 个字符。
`origin`	是	仅包含 scheme 和 host，例如 `https://pr-42.example.app`。不含 path、query 或凭据。
`sha`	否	Git commit hash
`branch`	否	Git 分支名
`actor`	否	谁触发了部署
`repo`	否	仓库名称
`prNumber`	否	Pull request 编号
`runUrl`	否	返回 CI 运行结果的链接

这些 git 字段被存储用于应用内的深度链接，没有任何逻辑分支依赖它们。

返回结果

有效请求始终响应 HTTP 200。结果或判定可以从响应的 data.check.status 中读取：

状态	含义
`pass`	每一项评分都在预算内
`breach`	至少有一项超出预算
`error`	没有可扫描的页面
`no-budgets`	没有页面有可用来评分的预算

注意：我们的服务器必须能通过公网访问该预览域名

2：部署后：RUM 验证

部署后检查和验证通过将 RUM 数据与你的部署匹配来实现。为了让我们能将数据匹配到你的部署，你可以轻松地将当前部署版本发送到我们的 API。

curl -sS -X POST "https://app.coredash.app/api/project/releases/ingest" \
  -H "Authorization: Bearer $COREDASH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"tag":"v1.2.3"}'

或者在 GitHub Actions 中全自动化，使用 git ref 作为版本：

- name: Report release to CoreDash
  if: success()
  env:
    COREDASH_API_KEY: ${{ secrets.COREDASH_API_KEY }}
  run: |
    curl -sS -f -X POST "https://app.coredash.app/api/project/releases/ingest" \
      -H "Authorization: Bearer ${COREDASH_API_KEY}" \
      -H "Content-Type: application/json" \
      -d "{\"tag\":\"${{ github.ref_name }}\"}"

没有流水线？没问题！CoreDash 的 releases 页面有一个 Tag deployment 表单。因为这需要手动操作且无法自动化，所以它不是必需的方法。

在 Core/Dash 中对比发布

Releases 页面列出了过去 30 天的记录，最新的排在最前：版本、来自 CI 还是应用、部署时间、每个 Core Web Vitals 的 p75 指标、与上一次发布的差值，以及实时预算状态。

Release detail 是两部分数据真正交汇的地方。部署前检查位于顶部，每个扫描页面的每条预算占一行。在其下方，使用相同的过滤器针对整个站点来衡量此次发布。这样你可以在同一屏幕上看到构建预期的效果以及用户实际体验到的结果。

coredash release results rum budgets

Performance Snapshots 可以在图表上画出部署标记，仅限已发布的版本。

coredash release markers

另见：使用 Core/Dash API 通过脚本或 AI 代理查询此类数据，了解这些判定使用的预算的警报与通知，以及如果你的站点还没安装追踪器，请查看安装指南。