Contrôles de performance automatiques Core/Dash CI/CD

Quel déploiement a causé le ralentissement ?

Votre LCP était de 2,1 secondes il y a deux mois. Il est de 2,9 secondes aujourd'hui. Vous avez déployé quarante fois depuis. Le problème : la chronologie seule ne vous dira pas quel déploiement a causé cela.

C'est pourquoi Core/Dash associe chaque visite de chaque utilisateur réel à un déploiement spécifique. Les données RUM doivent vous dire « la v2.4.1 a fait cela » au lieu de « quelque chose a ralenti le mois dernier ».

Core/Dash exécute deux contrôles autour de chaque déploiement. Avant le déploiement, Core/Dash analyse votre build de prévisualisation et déclenche une alerte dans le pipeline si une page dépasse le budget. Après le déploiement, chaque page vue est marquée avec la version du déploiement. Chaque version est ainsi mesurée par rapport à son propre trafic d'utilisateurs réels.

Les deux contrôles détectent les problèmes de Core Web Vitals à des moments différents. Le contrôle de pré-déploiement est synthétique. Il repère les erreurs présentes dans le build lui-même : la nouvelle image hero qui est un PNG de 4 Mo, le tag marketing qui a ajouté 300 Ko de script au bundle. Les contrôles post-déploiement sont de pures données RUM. Ils vous disent avec certitude ce qu'un déploiement fait réellement au LCP, à l'INP et au CLS.

1 : Pré-déploiement : contrôles synthétiques

Core/Dash peut analyser un échantillon de votre page surveillée. Les résultats sont comparés à vos propres budgets de performance Core/Dash. Si une page dépasse, vous êtes notifié avant le déploiement. Ce que vous faites de cette notification vous regarde.

Pour garder ce contrôle fiable, Core/Dash évalue uniquement les éléments qui ne changent pas entre deux exécutions du même build. Un score de performance Lighthouse peut varier de dix points entre deux exécutions de la même page. Ce score est dominé par les temps CPU, et la machine qui exécute l'audit n'est jamais la même. Évaluez cela en CI et vous obtenez des pipelines rouges qui ne signifient rien.

Ajoutez le contrôle à votre pipeline CI/CD

Créez d'abord une clé d'API de projet (dans l'application : votre projet, puis AI Insights, puis Connect Your AI). Ajoutez ensuite cette étape avant votre job de déploiement. Elle appelle le endpoint de contrôle et prend environ 30 à 45 secondes.

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 "Le contrôle CoreDash a échoué (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   ## décommentez pour bloquer le déploiement

Par défaut, cela signale uniquement le verdict dans vos logs CI. Décommentez la dernière ligne pour faire échouer le build lorsqu'une page dépasse le budget.

Schéma de données :

Les champs git sont stockés pour les liens profonds dans l'application. Aucune logique ne s'appuie dessus.

Ce qui est retourné

Une requête valide répond toujours HTTP 200. Les résultats ou le verdict peuvent être lus dans la réponse sous data.check.status :

Note : Le domaine de prévisualisation doit être accessible depuis l'internet public par nos serveurs

2 : Post-déploiement : validation RUM

Les contrôles et la validation post-déploiement se font en croisant les données RUM avec votre déploiement. Pour que nous puissions associer vos données à votre déploiement, envoyez simplement la version de déploiement actuelle à notre 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"}'

Ou de manière entièrement automatisée dans GitHub Actions, avec la référence git comme version :

- name: Signaler le déploiement à 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 }}\"}"

Pas de pipeline, pas de problème ! La page des déploiements CoreDash dispose d'un formulaire Tag deployment. Comme cela nécessite une action manuelle et ne peut pas être automatisé, ce n'est pas la méthode recommandée.

Comparer les déploiements dans Core/Dash

La page des déploiements liste les 30 derniers jours, du plus récent au plus ancien : version, provenance (CI ou application), heure de déploiement, p75 par Core Web Vital, delta par rapport au déploiement précédent, et statut du budget en temps réel.

Les détails du déploiement sont l'endroit où les deux moitiés se rencontrent. Le contrôle de pré-déploiement se trouve en haut, une ligne par page analysée et par ligne de budget. En dessous, le déploiement est mesuré sur l'ensemble du site avec les mêmes filtres. Vous pouvez ainsi voir ce que le build prétendait et ce que vos utilisateurs ont réellement obtenu, sur le même écran.

Les instantanés de performance peuvent dessiner des marqueurs de déploiement sur les graphiques, uniquement pour les versions publiées.

Voir aussi : l'API Core/Dash pour interroger ces données depuis un script ou un agent IA, les alertes et notifications pour les budgets utilisés par ces verdicts, et l'installation si le tracker n'est pas encore sur votre site.