Core/Dash CI/CD automatiska prestandakontroller

Vilken driftsättning gjorde sidan långsammare?

Din LCP var 2,1 sekunder för två månader sedan. Nu är den 2,9 sekunder. Du har gjort fyrtio driftsättningar sedan dess. Men här är problemet: tidslinjen i sig visar inte vilken driftsättning som orsakade detta.

Därför matchar Core/Dash varje besök från varje verklig användare till en specifik driftsättning. Vi anser att RUM-data bör berätta för dig ”v2.4.1 gjorde detta” i stället för ”något blev långsammare förra månaden”.

Core/Dash kör två kontroller kring varje driftsättning. Före driftsättning skannar Core/Dash ditt preview-bygge och flaggar pipelinen om en sida överskrider budget. Efter driftsättning taggas varje sidvisning med driftsättningsversionen, så att varje version mäts mot sin egen riktiga användartrafik.

De två kontrollerna fångar Core Web Vitals-problem vid olika tidpunkter. Kontrollen före driftsättning är syntetisk, så den ser misstag som finns i själva bygget: den nya hero-bilden som är en PNG på 4 MB, marknadsföringstaggen som lade till 300 KB skript i bundlen. Kontrollerna efter driftsättning är rena RUM-data. Det visar med säkerhet vad en release faktiskt gör med LCP, INP och CLS.

1: Före driftsättning: syntetiska kontroller

Core/Dash kan skanna ett urval av din övervakade sida. Resultaten jämförs med dina egna prestandabudgetar i Core/Dash. Om en sida ligger över budget får du ett meddelande innan du driftsätter. Vad du gör med det meddelandet är upp till dig.

För att hålla den kontrollen ärlig poängsätter Core/Dash bara saker som inte förändras mellan två körningar av samma bygge. En prestandapoäng i Lighthouse kan svänga tio poäng mellan två körningar av exakt samma sida. Den domineras av CPU-tider, och maskinen som kör mätningen är aldrig densamma två gånger. Poängsätt det i CI och du får röda pipelines som inte betyder någonting.

Lägg till kontrollen i din CI/CD-pipeline

Skapa först en projekt-API-nyckel (i appen: ditt projekt, sedan AI Insights, därefter Connect Your AI). Lägg sedan till detta steg innan ditt deploy-jobb. Det anropar check-endpointen och tar cirka 30 till 45 sekunder.

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

Som standard rapporterar detta enbart utslaget till dina CI-loggar. Avkommentera den sista raden för att låta bygget misslyckas när en sida överstiger budgeten.

Dataschema:

Git-fälten lagras för djuplänkar i appen och ingen logik bygger på dem.

Vad som returneras

En giltig förfrågan svarar alltid HTTP 200. Resultaten eller utslaget kan läsas från resultatet under data.check.status:

Obs: Preview-domänen måste vara nåbar från det publika internet för våra servrar

2: Efter driftsättning: RUM-validering

Kontroller och validering efter driftsättning sker genom att RUM-data matchas mot din driftsättning. För att vi ska kunna matcha din data mot din driftsättning kan du enkelt skicka den aktuella driftsättningsversionen till vårt 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"}'

Eller helt automatiserat i GitHub Actions, med git-referensen som 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 }}\"}"

Ingen pipeline, inga problem! Release-sidan i CoreDash har ett Tag deployment-formulär. Eftersom detta kräver en manuell åtgärd och inte kan automatiseras är det inte den krävda metoden.

Jämföra releaser i Core/Dash

Releases-sidan listar de senaste 30 dagarna, nyaste först: version, om den kom från CI eller appen, driftsättningstid, p75 per Core Web Vital, skillnaden mot föregående release och en live-status för budgeten.

Release detail är där de två halvorna faktiskt möts. Kontrollen före driftsättning ligger överst, en rad per skannad sida per budgetrad. Därunder mäts releasen mot hela webbplatsen med samma filter, så du kan se vad bygget utlovade och vad dina användare faktiskt fick på en och samma skärm.

Performance Snapshots kan rita ut driftsättningsmarkörer i diagrammen, enbart för släppta versioner.

Se även: Core/Dash-API:et för att hämta denna data från ett skript eller en AI-agent, larm och aviseringar för budgetarna som dessa utslag använder, och installation om trackern ännu inte finns på din webbplats.