Core/Dash CI/CD 自動パフォーマンスチェック

1回のcurl呼び出しで、Core/DashをCI/CDパイプラインに統合します。リリース前にパフォーマンス予算をオーバーしたビルドを警告します。すべてのデプロイにおいて、実際のユーザーパフォーマンスを追跡します。

無料トライアル

Trusted by market leaders · Client results

fotocasaworkivamy work featured on web.devdpg mediawhowhatwearcompareperionebayharvardkpnmonarchsnvvpnnestlesaturnloopearplugsadevintaaleteiaerasmusmcmarktplaatshappyhorizonnina care

どのデプロイが原因で遅くなったのか？

2ヶ月前のLCPは2.1秒でした。現在は2.9秒です。その間に40回デプロイしています。問題は、タイムラインを見るだけではどのデプロイが原因か分からないことです。

そのため、Core/Dashは実際のユーザーからのすべてのアクセスを特定のデプロイに紐付けます。RUMデータは「先月何かが遅くなった」ではなく、「v2.4.1が原因である」と示すべきです。

Core/Dashは、各デプロイの前後で2つのチェックを実行します。デプロイ前にはプレビュービルドをスキャンし、ページが予算をオーバーしている場合はパイプラインに警告を出します。デプロイ後は、すべてのページビューにデプロイバージョンがタグ付けされます。各バージョンは、自身の実際のユーザートラフィックに対して測定されます。

この2つのチェックは、異なるタイミングでCore Web Vitalsの問題を捕捉します。デプロイ前のチェックはシンセティックテストであり、ビルド自体に潜むミスを見つけます。4MBのPNGになった新しいヒーロー画像や、バンドルに300KBのスクリプトを追加したマーケティングタグなどです。デプロイ後のチェックは純粋なRUMデータです。リリースがLCP、INP、CLSに実際にもたらす影響を確実に示します。

1: デプロイ前: シンセティックチェック

Core/Dashは監視対象ページのサンプルをスキャンできます。結果は、独自のCore/Dashパフォーマンス予算と比較されます。ページが予算を超過している場合は、デプロイ前に通知されます。通知をどう扱うかは自由です。

このチェックの正確性を保つため、Core/Dashは同じビルドを2回実行しても変わらない要素のみをスコア化します。Lighthouseのパフォーマンススコアは、全く同じページを2回実行しても10ポイント変動することがあります。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   ## uncomment to block the deploy

デフォルトでは、判定結果がCIログに報告されるだけです。ページが予算を超過した場合にビルドを失敗させるには、最後の行のコメントを外してください。

データスキーマ:

フィールド必須説明
tagはいバージョン文字列。文字、数字、. _ / -を使用し、最大64文字。
originはいスキームとホストのみ。例: https://pr-42.example.app。パス、クエリ、認証情報は不可。
shaいいえGitコミットハッシュ
branchいいえGitブランチ名
actorいいえデプロイのトリガー元
repoいいえリポジトリ名
prNumberいいえプルリクエスト番号
runUrlいいえCI実行結果へのリンク

Git関連のフィールドはアプリ内のディープリンク用に保存されます。これによって処理が分岐することはありません。

レスポンス内容

有効なリクエストは常にHTTP 200を返します。結果や判定は、結果のdata.check.statusから読み取れます:

ステータス意味
passスコア化されたすべての項目が予算内
breach少なくとも1つの項目が予算を超過
errorスキャンできたページがない
no-budgetsスコア化できる予算が設定されたページがない

注意: プレビュードメインは、CoreDashのサーバーからパブリックインターネット経由でアクセスできる必要があります

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"}'

あるいは、gitのrefをバージョンとして使用し、GitHub Actionsで完全に自動化することもできます:

- 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のリリースページにはデプロイのタグ付けフォームがあります。これは手動操作が必要で自動化できないため、必須の方法ではありません。

Core/Dashでのリリースの比較

リリース（Releases）ページには、過去30日間の履歴が新しい順に一覧表示されます。バージョン、CIとアプリのどちらから送信されたか、デプロイ時間、各Core Web Vitalsのp75値、前回リリースからの差分、現在の予算ステータスが確認できます。

リリース詳細（Release detail）では、これら2つの要素が交わります。上部にはデプロイ前のチェックが、スキャンされたページおよび予算項目ごとに1行ずつ表示されます。その下には、同じフィルター条件でサイト全体に対して測定されたリリースの結果が表示されます。これにより、ビルド時の予測と実際のユーザー体験を同じ画面で比較できます。

パフォーマンススナップショット（Performance Snapshots）では、チャート上にデプロイのマーカーを描画できます。対象はリリースされたバージョンのみです。

関連情報: スクリプトやAIエージェントからデータを照会する場合はCore/Dash APIを、これらの判定に使用される予算についてはアラートと通知を、トラッカーがまだサイトに導入されていない場合はインストールを参照してください。