Core/Dash CI/CD automatiska prestandatester

Vilken deploy gjorde det långsammare?

Din LCP var 2,1 sekunder för två månader sedan. Nu är den 2,9 sekunder. Du har gjort fyrtio deploys sedan dess, och tidslinjen i sig talar inte om för dig vilken deploy som orsakade det.

Därför matchar Core/Dash varje besök från varje verklig användare mot en specifik deploy. Regressionen blir ”v2.4.1 gjorde detta” i stället för ”något blev långsammare förra månaden”.

Core/Dash kör två tester kring varje deploy. Innan den släpps skannar Core/Dash ditt preview-bygge och flaggar pipelinen om en sida går över budget. Efter att den har släppts taggas varje sidvisning med den version som levererade den, så varje release mäts mot sin egen trafik från verkliga användare.

De två testerna fångar olika typer av fel. Pre-deploy-testet är syntetiskt, så det 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 din bundle. Vad en release faktiskt gör med LCP, INP och CLS syns bara i field data, eftersom ett datacenter i Iowa inte är dina verkliga användares Android-telefon på 4G i New York.

Före deployen: testa preview-bygget

Core/Dash testar de första fyra övervakade sidorna som har en Lighthouse-budget den kan poängsätta, och kör var och en mot din preview-miljö i stället för produktion. Det jämförs med dina egna Core/Dash-prestandabudgetar. Om en sida ligger över budget meddelas du innan du gör din deploy. Vad du gör med den aviseringen är upp till dig.

För att hålla testet ärligt poängsätter Core/Dash bara mätvärden som inte ändras mellan två körningar av samma bygge. En Lighthouse-prestandapoäng kan pendla tio poäng mellan två körningar av exakt samma sida, eftersom den domineras av CPU-tider och maskinen som kör testet aldrig är 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 testet i din CI/CD-pipeline

Skapa först en projekt-API-nyckel (i appen: ditt projekt, sedan AI Insights, sedan Connect Your AI). Lägg sedan till det här steget före ditt deploy-jobb. Det anropar check-ändpunkten 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-testet kunde inte köras (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   ## avkommentera för att blockera deployen

Som standard rapporteras utfallet bara till dina CI-loggar. Avkommentera den sista raden för att faila bygget när en sida är över budget.

Variabler:

Git-fälten lagras för djuplänkar i appen och ingen logik styrs av dem.

Returvärden:

Ett giltigt anrop svarar alltid HTTP 200. Utfallet finns i data.check.status:

Testet kör fail open, per sida. Om PageSpeed Insights får en timeout på en av de fyra, kommer den sidan tillbaka som ett fel och de andra tre poängsätts fortfarande, så en dålig minut hos Google blockerar inte din release. Två saker följer av den designen. Din preview måste vara nåbar från det publika nätet, eftersom Google hämtar den (en lösenordsskyddad preview kan inte skannas, så peka testet mot en publik staging-origin i stället). Och preview-siffror hamnar aldrig på din budget-board för produktion.

Efter deployen: registrera releasen

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

I GitHub Actions, med git-refen som version:

- name: Rapportera release till 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 }}\"}"

Alla CI som kan köra curl fungerar. GitLab, Jenkins, CircleCI, ett bash-deploy-skript på en server någonstans. Skicka in samma tag som du skickade till testet, eftersom det är det som knyter ihop skanningsresultatet och mätvärdena från verkliga användare till en enda release.

deployedAt är valfritt och sätts som standard till nu. Sätt den i det förflutna för att bakåtdatera en deploy du redan har släppt. notes tar upp till 2000 tecken, och git-fälten från testet fungerar här också. En release är unik per projekt och tagg, så om du postar en tagg igen uppdateras den raden i stället för att skapa en ny, och en rollback knyts tillbaka till den release den tillhör.

Ingen pipeline? Sidan Releases har ett formulär för Tag deployment. Det är det svagare alternativet och värt att vara ärlig om, eftersom det bara registrerar de deploys någon kommer ihåg att skriva in, vid den tidpunkt de råkar komma ihåg det.

Hur trafik kopplas

När du registrerar en release stämplas den på projektet som den aktuella versionen. Servern som levererar ditt spårningsskript läser av den stämpeln och injicerar taggen i snippeten, så varje sidvisning från och med då bär med sig versionen i rel-dimensionen. Edge-kopian rensas från Cloudflare i samma ögonblick som stämpeln flyttas, så du väntar inte på en CDN-cache. Om din app känner till sitt eget build-id och din CI inte gör det, sätt window.__CWVREL innan trackern laddas så vinner den (håll det till en riktig versionssträng, eftersom en build-hash per anrop ger dig ett nytt dimensionsvärde vid varje sidvisning och försämrar varje grupperad query du kör).

Dina metrics hittar sin release enbart via den taggen och ingenting annat. Det finns ingen time-window-fallback där Core/Dash gissar att trafik mellan två tidsstämplar förmodligen tillhör en release. En release utan taggad trafik visar bindestreck, vilket är bättre än en siffra som i tysthet krediterar den föregående versionens användare till din nya. Ge den ungefär 200 sidvisningar innan du förväntar dig ett utfall. Under det är pass eller fail bara brus.

Dessa utfall kommer från de RUM-budgetar du redan kör på varningar och aviseringar-sidan. Det finns ingen separat uppsättning tröskelvärden att konfigurera.

Release-statusar

Bara released stämplar projektet och taggar din trafik. Versioner som inte har släppts visas fortfarande på tidslinjen, märkta som ”Blocked” eller ”Awaiting deploy”, och en blockerad rad bär med sig de metrics som gick över gränsen, så en vecka senare kan du fortfarande se varför den versionen aldrig gick ut.

Vad du ser i Core/Dash

Releases-sidan listar de senaste 30 dagarna, nyast först: version, om den kom från CI eller appen, deploy-tid, p75 per Core Web Vital, deltat mot föregående release, och en live budgetstatus.

Release detail lägger pre-deploy-testet överst, en rad per skannad sida per budgetrad, med releasens resultat för hela sajten under det.

Performance Snapshots kan rita ut deploy-markörer i diagrammen. Markörer visas bara för versioner som släppts, så ett blockerat bygge dyker aldrig upp bredvid trafik det aldrig har serverat.

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