Core/Dash CI/CD automatische performance checks

Welke deploy maakte het trager?

Je LCP was twee maanden geleden 2,1s. Nu is het 2,9s. Je hebt sindsdien veertig keer gedeployd. Maar hier is het probleem: de tijdlijn alleen vertelt je niet welke deploy dit veroorzaakte.

Daarom koppelt Core/Dash elk bezoek van elke echte gebruiker aan een specifieke deployment. Wij geloven dat RUM data je moet vertellen "v2.4.1 deed dit" in plaats van "iets is vorige maand trager geworden".

Core/Dash voert twee checks uit rondom elke deploy. Voor de deployment scant Core/Dash je preview build en markeert de pipeline als een pagina over budget gaat. Na de deployment krijgt elke pageview de tag van de deploymentversie, zodat elke versie wordt gemeten aan de hand van het eigen verkeer van echte gebruikers.

De twee checks vangen Core Web Vitals-problemen op verschillende momenten af. De pre-deploy check is synthetisch, dus deze ziet fouten die in de build zelf zitten: de nieuwe hero image die een PNG van 4MB is, de marketing tag die 300KB aan script toevoegde aan de bundel. De post-deployment checks zijn pure RUM data. Dat vertelt je met zekerheid wat een release daadwerkelijk doet met LCP, INP en CLS.

1: Pre-deployment: synthetische checks

Core/Dash kan een sample van je gemonitorde pagina scannen. Het resultaat wordt vergeleken met je eigen Core/Dash performancebudgetten. Als een pagina hier overheen gaat, krijg je een melding voordat je deployt. Wat je met die melding doet, is aan jou.

Om die check eerlijk te houden, scoort Core/Dash alleen dingen die niet veranderen tussen twee runs van dezelfde build. Een Lighthouse performance score kan tien punten schommelen tussen twee runs van exact dezelfde pagina, omdat deze gedomineerd wordt door CPU-timings en de machine die de audit draait nooit twee keer hetzelfde is. Scoor dat in CI en je krijgt rode pipelines die niets betekenen.

Voeg de check toe aan je CI/CD pipeline

Maak eerst een project API-key aan (in de app: je project, dan AI Insights, dan Connect Your AI). Voeg vervolgens deze stap toe vóór je deploy job. Deze roept het check endpoint aan en duurt ongeveer 30 tot 45 seconden.

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

Standaard rapporteert dit alleen het oordeel aan je CI-logs. Haal de laatste regel uit commentaar om de build te laten falen wanneer een pagina over budget is.

Dataschema:

De git-velden worden opgeslagen voor deep links in de app. Er wordt geen logica op gebaseerd.

Wat je terugkrijgt

Een geldig verzoek beantwoordt altijd met HTTP 200. Het resultaat of oordeel lees je af onder data.check.status:

Let op: het preview-domein moet vanaf het publieke internet bereikbaar zijn voor onze servers

2: Post-deployment: RUM-validatie

Post-deployment checks en validatie gebeuren door de RUM data te matchen met je deployment. Om je data aan je deployment te kunnen koppelen, stuur je eenvoudig de huidige deploymentversie naar onze 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"}'

Of volledig geautomatiseerd in GitHub Actions, met de git ref als versie:

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

Geen pipeline, geen probleem! De CoreDash releases-pagina heeft een Tag deployment-formulier. Omdat dit een handmatige actie vereist en niet geautomatiseerd kan worden, is dit niet de aanbevolen methode.

Releases vergelijken in Core/Dash

De Releases-pagina toont de laatste 30 dagen, nieuwste eerst: versie, of het uit CI of de app kwam, deploytijd, p75 per Core Web Vital, de delta ten opzichte van de vorige release, en een live budgetstatus.

Release detail is waar de twee helften samenkomen. De pre-deploy check staat bovenaan, één rij per gescande pagina per budgetregel. Daaronder wordt de release gemeten tegen de hele site met dezelfde filters. Zo zie je op hetzelfde scherm wat de build beloofde en wat je gebruikers daadwerkelijk kregen.

Performance Snapshots kunnen deploy-markers tekenen op de grafieken, alleen voor gereleasete versies.

Zie ook: de Core/Dash API om deze data te bevragen vanuit een script of een AI-agent, alerts en notificaties voor de budgetten die deze oordelen gebruiken, en installatie als de tracker nog niet op je site staat.