Core/Dash CI/CD automatiske ytelsessjekker

Hvilken deploy gjorde det tregere?

LCP-en din var 2,1 sekunder for to måneder siden. Nå er den 2,9 sekunder. Du har deployet førti ganger siden da. Men her er problemet: Tidslinjen alene forteller deg ikke hvilken deploy som forårsaket dette.

Derfor kobler Core/Dash hvert besøk fra hver ekte bruker til en spesifikk deploy. Vi mener RUM-data bør fortelle deg «v2.4.1 gjorde dette» i stedet for «noe ble tregere forrige måned».

Core/Dash kjører to sjekker for hver deploy. Før deploy skanner Core/Dash preview-bygget ditt og flagger pipelinen hvis en side overskrider budsjettet. Etter deploy blir hver sidevisning tagget med deploy-versjonen, slik at hver versjon måles mot sin egen trafikk fra ekte brukere.

De to sjekkene fanger opp problemer med Core Web Vitals på ulike tidspunkter. Sjekken før deploy er syntetisk, så den ser feil som ligger i selve bygget: det nye hero-bildet som er en 4MB PNG, eller markedsføringstaggen som la til 300KB med skript i bundelen. Sjekkene etter deploy er rene RUM-data. Dette forteller deg med sikkerhet hva en release faktisk gjør med LCP, INP og CLS.

1: Før deploy: syntetiske sjekker

Core/Dash kan skanne et utvalg av de overvåkede sidene dine. Resultatene sammenlignes med dine egne ytelsesbudsjetter i Core/Dash. Hvis en side overskrider budsjettet, får du varsel før du deployer. Hva du gjør med det varselet er opp til deg.

For å holde sjekken ærlig, scorer Core/Dash kun ting som ikke endrer seg mellom to kjøringer av samme bygg. En Lighthouse-score kan svinge med ti poeng mellom to kjøringer av nøyaktig samme side, fordi den domineres av CPU-tider og maskinen som kjører revisjonen aldri er den samme to ganger. Scorer du dette i CI, får du røde pipeliner som ikke betyr noen ting.

Legg til sjekken i CI/CD-pipelinen din

Lag en prosjekt-API-nøkkel først (i appen: prosjektet ditt, deretter AI Insights, så Connect Your AI). Legg deretter til dette steget før deploy-jobben din. Det kaller sjekk-endepunktet og tar omtrent 30 til 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   ## fjern kommentar for å blokkere deployen

Som standard rapporterer dette kun dommen til CI-loggene dine. Fjern kommenteringen på den siste linjen for å feile bygget når en side er over budsjett.

Dataskjema:

Git-feltene lagres for dyplenker i appen, og de påvirker ingen logikk.

Hva du får tilbake

En gyldig forespørsel svarer alltid med HTTP 200. Resultatene eller dommen kan leses fra resultatet under data.check.status:

Merk: Preview-domenet må være tilgjengelig fra det åpne internettet for serverne våre

2: Etter deploy: RUM-validering

Sjekker og validering etter deploy skjer ved å matche RUM-dataene mot din deploy. For at vi skal kunne matche dataene dine mot deployen din, kan du enkelt sende gjeldende deploy-versjon til API-et vårt. 

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 fullstendig automatisert i GitHub Actions, med git ref som versjon:

- name: Rapporter release til 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, ikke noe problem! CoreDash sin releases-side har et Tag deployment-skjema. Fordi dette krever en manuell handling og ikke kan automatiseres, er ikke dette den påkrevde metoden.

Sammenligning av releaser i Core/Dash

Releases-siden lister opp de siste 30 dagene, nyeste først: versjon, om den kom fra CI eller appen, tidspunkt for deploy, p75 per Core Web Vital, delta mot forrige release, og en live budsjettstatus.

Release detail er der de to halvdelene faktisk møtes. Sjekken før deploy ligger øverst, én rad per skannede side per budsjettlinje. Under dette måles releasen mot hele nettstedet under de samme filtrene, slik at du kan se hva bygget påsto og hva brukerne dine faktisk fikk, på én og samme skjerm.

Performance Snapshots kan tegne deploy-markører på diagrammene, kun for utgitte versjoner.

Se også: Core/Dash API for å hente disse dataene fra et skript eller en AI-agent, varsler og notifikasjoner for budsjettene disse dommene bruker, og installasjon hvis trackeren ikke er på nettstedet ditt ennå.