Core/Dash CI/CD automatiske performance-tjek

Hvilket deploy gjorde det langsommere?

Din LCP var 2,1 sekunder for to måneder siden. Den er 2,9 sekunder nu. Du har deployet fyrre gange siden da. Men her er problemet: tidslinjen alene fortæller dig ikke, hvilket deploy der forårsagede dette.

Derfor matcher Core/Dash hvert besøg fra hver rigtig bruger med et specifikt deployment. Vi mener, at RUM-data bør fortælle dig, at "v2.4.1 gjorde dette" i stedet for "noget blev langsommere i sidste måned."

Core/Dash kører to tjek ved hvert deploy. Før deployment scanner Core/Dash dit preview-build og markerer pipelinen, hvis en side overskrider budgettet. Efter deployment tagges hver sidevisning med deployment-versionen, så hver version måles mod sin egen trafik fra rigtige brugere.

De to tjek fanger Core Web Vitals-problemer på forskellige tidspunkter. Pre-deploy-tjekket er syntetisk, så det ser fejl, der findes i selve buildet: det nye hero-billede, som er en PNG på 4MB, marketing-tagget, der tilføjede 300KB script til bundlet. Post-deployment-tjekkene er rene RUM-data. Det fortæller dig med sikkerhed, hvad et release rent faktisk gør ved LCP, INP og CLS.

1: Pre-deployment: syntetiske tjek

Core/Dash kan scanne et udsnit af din overvågede side. Resultaterne sammenlignes med dine egne Core/Dash performance-budgetter. Hvis en side overskrider, får du besked, før du deployer. Hvad du gør med den besked, er op til dig.

For at holde det tjek ærligt, scorer Core/Dash kun ting, der ikke ændrer sig mellem to kørsler af det samme build. En Lighthouse performance-score kan svinge ti point mellem to kørsler af præcis samme side, fordi den er domineret af CPU-tider, og maskinen, der kører auditen, aldrig er den samme to gange. Scorer du det i CI, får du røde pipelines, der ikke betyder noget.

Tilføj tjekket til din CI/CD-pipeline

Opret først en projekt API-nøgle (i appen: dit projekt, derefter AI Insights, derefter Connect Your AI). Tilføj så dette trin før dit deploy-job. Det kalder check-endpointet og tager cirka 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 udkommentering for at blokere deployet

Som standard rapporterer dette kun dommen til dine CI-logs. Fjern udkommenteringen af den sidste linje for at få buildet til at fejle, når en side overskrider budgettet.

Dataskema:

Git-felterne gemmes til dybe links i appen, og intet forgrener sig baseret på dem.

Hvad der kommer tilbage

Et gyldigt request svarer altid HTTP 200. Resultaterne eller dommen kan læses fra resultatet under data.check.status:

Bemærk: Preview-domænet skal være tilgængeligt fra det offentlige internet for vores servere

2: Post-deployment: RUM-validering

Post-deployment-tjek og validering sker ved at matche RUM-dataene mod dit deployment. For at vi kan matche dine data med dit deployment, kan du nemt sende den aktuelle deployment-version til vores 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 fuldautomatisk i GitHub Actions, med git-ref som versionen:

- 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, intet problem! CoreDash releases-siden har en Tag deployment-formular. Fordi dette kræver en manuel handling og ikke kan automatiseres, er dette ikke den krævede metode.

Sammenligning af releases i Core/Dash

Releases-siden viser de seneste 30 dage, nyeste først: version, om det kom fra CI eller appen, deploy-tidspunkt, p75 per Core Web Vital, forskellen i forhold til det forrige release, og en live budgetstatus.

Release detail er der, hvor de to halvdele rent faktisk mødes. Pre-deploy-tjekket ligger øverst med én række per scannet side per budgetlinje. Nedenunder måles releaset mod hele sitet under de samme filtre. Så kan du se, hvad buildet påstod, og hvad dine brugere rent faktisk fik, på samme skærm.

Performance Snapshots kan tegne deploy-markører på graferne, kun for udgivne versioner.

Se også: Core/Dash API til at forespørge disse data fra et script eller en AI-agent, alarmer og notifikationer for de budgetter disse domme bruger, og installation hvis trackeren endnu ikke er på dit site.