Core/Dash CI/CD controlli automatici di performance

Quale deploy l'ha reso più lento?

Il tuo LCP era di 2,1s due mesi fa. Ora è di 2,9s. Da allora hai effettuato quaranta deploy. Ma ecco il problema: la timeline da sola non ti dirà quale deploy ha causato questo.

Ecco perché Core/Dash associa ogni visita di ogni utente reale a un deploy specifico. Crediamo che i dati RUM debbano dirti "la v2.4.1 ha causato questo" invece di "qualcosa è rallentato il mese scorso".

Core/Dash esegue due controlli attorno a ogni deploy. Prima del deploy, Core/Dash scansiona la tua build di anteprima e segnala la pipeline se una pagina supera il budget. Dopo il deploy, ogni visualizzazione di pagina viene taggata con la versione del deploy, così ogni versione viene misurata rispetto al proprio traffico di utenti reali.

I due controlli catturano i problemi dei Core Web Vitals in momenti diversi. Il controllo pre-deploy è sintetico, quindi vede gli errori che risiedono nella build stessa: la nuova immagine hero che è una PNG da 4MB, il tag di marketing che ha aggiunto 300KB di script al bundle. I controlli post-deploy sono puri dati RUM. Questo ti dice con certezza cosa fa effettivamente una release a LCP, INP e CLS.

1: Pre-deploy: controlli sintetici

Core/Dash può scansionare un campione della tua pagina monitorata. I risultati vengono confrontati con i tuoi budget di performance di Core/Dash. Se una pagina li supera, ricevi una notifica prima del deploy. Cosa fai con quella notifica dipende da te.

Per mantenere onesto questo controllo, Core/Dash valuta solo le cose che non cambiano tra due esecuzioni della stessa build. Un punteggio di performance di Lighthouse può oscillare di dieci punti tra due esecuzioni della stessa identica pagina, perché è dominato dalle tempistiche della CPU e la macchina che esegue l'audit non è mai la stessa due volte. Valuta questo in CI e otterrai pipeline rosse che non significano nulla.

Aggiungi il controllo alla tua pipeline CI/CD

Crea prima una chiave API di progetto (nell'app: il tuo progetto, poi AI Insights, quindi Connect Your AI). Aggiungi poi questo passaggio prima del tuo job di deploy. Chiama l'endpoint del controllo e impiega dai 30 ai 45 secondi.

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   ## decommenta per bloccare il deploy

Di default questo riporta il verdetto solo nei log della tua CI. Decommenta l'ultima riga per far fallire la build quando una pagina supera il budget.

Schema dati:

I campi git vengono salvati per i deep link nell'app e nessuna logica dipende da essi.

Cosa viene restituito

Una richiesta valida risponde sempre HTTP 200. I risultati o il verdetto possono essere letti dal risultato in data.check.status:

Nota: Il dominio di anteprima deve essere raggiungibile da internet pubblico dai nostri server

2: Post-deploy: validazione RUM

I controlli post-deploy e la validazione avvengono confrontando i dati RUM con il tuo deploy. Affinché noi possiamo associare i tuoi dati al tuo deploy, puoi semplicemente inviare la versione attuale del deploy alla nostra 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"}'

Oppure in modo completamente automatico in GitHub Actions, con la ref di git come versione:

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

Nessuna pipeline, nessun problema! La pagina delle release di CoreDash ha un modulo Tag deployment. Poiché richiede un'azione manuale e non può essere automatizzato, questo non è il metodo richiesto.

Confrontare le release in Core/Dash

La pagina Releases elenca gli ultimi 30 giorni, dai più recenti: la versione, se proviene dalla CI o dall'app, l'ora del deploy, il p75 per ogni Core Web Vital, il delta rispetto alla release precedente e uno stato del budget in tempo reale.

Il dettaglio della release è dove le due metà si incontrano. Il controllo pre-deploy si trova in alto, una riga per pagina scansionata per riga di budget, e sotto di esso la release viene misurata su tutto il sito con gli stessi filtri, così puoi vedere cosa ha dichiarato la build e cosa hanno effettivamente ottenuto i tuoi utenti sulla stessa schermata.

Gli Snapshot di performance possono disegnare marker di deploy sui grafici, solo per le versioni rilasciate.

Vedi anche: l'API di Core/Dash per interrogare questi dati da uno script o un agente AI, alert e notifiche per i budget usati da questi verdetti e l'installazione se il tracker non è ancora sul tuo sito.