Core/Dash CI/CD automatische Performance-Checks

Welches Deployment hat es langsamer gemacht?

Dein LCP lag vor zwei Monaten bei 2,1 s. Jetzt liegt er bei 2,9 s. Du hast seitdem vierzig Mal deployed. Das Problem: Die Zeitachse allein sagt dir nicht, welches Deployment das verursacht hat.

Deshalb ordnet Core/Dash jeden Besuch eines echten Nutzers einem spezifischen Deployment zu. Wir glauben, RUM-Daten sollten dir sagen: „v2.4.1 hat das verursacht“, statt „letzten Monat ist etwas langsamer geworden“.

Core/Dash führt bei jedem Deployment zwei Checks durch. Vor dem Deployment scannt Core/Dash deinen Preview-Build und markiert die Pipeline, wenn eine Seite das Budget überschreitet. Nach dem Deployment wird jeder Seitenaufruf mit der Deployment-Version getaggt. So wird jede Version gegen ihren eigenen Traffic echter Nutzer gemessen.

Die beiden Checks finden Core Web Vitals-Probleme zu unterschiedlichen Zeiten. Der Pre-Deploy-Check ist synthetisch. Er sieht Fehler direkt im Build: das neue Hero-Bild, das ein 4 MB großes PNG ist, das Marketing-Tag, das 300 KB Skript zum Bundle hinzugefügt hat. Die Post-Deployment-Checks sind reine RUM-Daten. Das sagt dir mit Sicherheit, was ein Release tatsächlich mit LCP, INP und CLS macht.

1: Pre-Deployment: synthetische Checks

Core/Dash kann eine Stichprobe deiner überwachten Seite scannen. Die Ergebnisse werden mit deinen eigenen Core/Dash-Performance-Budgets verglichen. Ist eine Seite drüber, wirst du vor dem Deployment benachrichtigt. Was du mit dieser Benachrichtigung machst, liegt bei dir.

Um diesen Check ehrlich zu halten, bewertet Core/Dash nur Dinge, die sich zwischen zwei Durchläufen desselben Builds nicht ändern. Ein Lighthouse-Performance-Score kann zwischen zwei Durchläufen exakt derselben Seite um zehn Punkte schwanken. Er wird von CPU-Timings dominiert. Die Maschine für den Audit ist nie zweimal dieselbe. Bewerte das in der CI, und du bekommst rote Pipelines, die nichts bedeuten.

Füge den Check zu deiner CI/CD-Pipeline hinzu

Erstelle zuerst einen Projekt-API-Key (in der App: dein Projekt, dann AI Insights, dann Connect Your AI). Füge dann diesen Schritt vor deinem Deploy-Job hinzu. Er ruft den Check-Endpunkt auf und dauert etwa 30 bis 45 Sekunden.

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   ## entkommentieren, um das Deployment zu blockieren

Standardmäßig meldet dies das Urteil nur an deine CI-Logs. Entkommentiere die letzte Zeile, um den Build fehlschlagen zu lassen, wenn eine Seite über dem Budget liegt.

Datenschema:

Die Git-Felder werden für Deep Links in der App gespeichert. Sie steuern keine Logik.

Was zurückkommt

Eine gültige Anfrage antwortet immer mit HTTP 200. Die Ergebnisse oder das Urteil können aus dem Ergebnis unter data.check.status abgelesen werden:

Hinweis: Die Preview-Domain muss für unsere Server aus dem öffentlichen Internet erreichbar sein.

2: Post-Deployment: RUM-Validierung

Post-Deployment-Checks und Validierung erfolgen durch den Abgleich der RUM-Daten mit deinem Deployment. Damit wir deine Daten deinem Deployment zuordnen können, kannst du einfach die aktuelle Deployment-Version an unsere API senden. 

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

Oder vollautomatisch in GitHub Actions, mit der Git-Ref als Version:

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

Keine Pipeline, kein Problem! Die CoreDash-Releases-Seite hat ein Deployment taggen-Formular. Da dies eine manuelle Aktion erfordert und nicht automatisiert werden kann, ist dies nicht die empfohlene Methode.

Releases in Core/Dash vergleichen

Die Releases-Seite listet die letzten 30 Tage auf, die neuesten zuerst: Version, ob sie aus der CI oder der App kam, Deploy-Zeitpunkt, p75 pro Core Web Vital, das Delta zum vorherigen Release und ein Live-Budget-Status.

In den Release-Details treffen die beiden Hälften aufeinander. Der Pre-Deploy-Check steht oben, eine Zeile pro gescannter Seite pro Budget-Zeile. Darunter wird das Release unter denselben Filtern gegen die gesamte Seite gemessen. So siehst du auf einem Bildschirm, was der Build behauptet hat und was deine Nutzer tatsächlich bekommen haben.

Performance Snapshots können Deploy-Marker in den Diagrammen zeichnen, nur für veröffentlichte Versionen.

Siehe auch: Die Core/Dash API, um diese Daten über ein Skript oder einen KI-Agenten abzufragen. Warnungen und Benachrichtigungen für die Budgets, die diese Urteile verwenden. Und Installation, falls der Tracker noch nicht auf deiner Seite ist.