Blocage des builds en CI et marqueurs de déploiement

Vous pouvez lancer un moniteur Page Speed depuis votre pipeline CI et faire échouer le build quand la page dépasse un budget, pour qu'une version lente soit arrêtée avant d'atteindre vos visiteurs. La même étape peut marquer le déploiement sur les graphiques d'historique du moniteur, pour qu'un ralentissement apparaisse à côté de la version qui l'a provoqué.

Tout passe par un petit script disponible à https://speed.loadfocus.com/ci.js. Il demande Node 14 ou plus récent et n'a aucune dépendance : il fonctionne donc dans GitHub Actions et dans toute autre CI qui exécute Node.

Avant de commencer

• Un moniteur pour la page. Le script lance un moniteur que vous avez déjà, voir Premiers pas.
• L'identifiant du moniteur. Ouvrez un résultat du moniteur et descendez jusqu'à CI et marqueurs de déploiement, sous les graphiques d'historique. L'étape affichée sous Faire échouer un build quand cette page ralentit contient déjà l'identifiant, et Copier la place dans le presse-papiers. L'identifiant est aussi la partie qui suit /speedtests/ dans l'adresse de la page de résultat.
• Une clé API. Créez-en une sur la page API Keys et enregistrez-la comme secret CI nommé LOADFOCUS_API_KEY. Si vous travaillez dans plusieurs équipes, définissez aussi LOADFOCUS_TEAM_ID ; sans elle, votre équipe par défaut est utilisée.

Chaque exécution CI lance une vraie exécution du moniteur et compte donc comme une exécution de test de votre plan.

Exemple GitHub Actions

Ajoutez votre clé API comme secret du dépôt (Settings > Secrets and variables > Actions > LOADFOCUS_API_KEY), puis créez .github/workflows/page-speed.yml :

name: Page speed budget

on:
  push:
    branches: [ main ]

jobs:
  page-speed:
    runs-on: ubuntu-latest
    steps:
      - name: Page speed budget
        run: curl -fsSL https://speed.loadfocus.com/ci.js | node - --monitor YOUR_MONITOR_ID --marker "${{ github.sha }}" --budget "lcp<=2.5"
        env:
          LOADFOCUS_API_KEY: ${{ secrets.LOADFOCUS_API_KEY }}

Remplacez YOUR_MONITOR_ID par l'identifiant de votre moniteur. L'étape publie un marqueur de déploiement libellé avec le commit, lance le moniteur, attend le résultat et fait échouer le job quand un budget est dépassé. Placez-la après votre étape de déploiement pour qu'elle mesure la version que vous venez de livrer.

Pour relier le marqueur à la page du commit, ajoutez --marker-url "${{ github.server_url }}/${{ github.repository }}/commit/${{ github.sha }}". Répétez --budget pour d'autres limites, par exemple --budget "lcp<=2.5" --budget "performance>=90".

Options

curl -fsSL https://speed.loadfocus.com/ci.js | node - --help affiche la même liste.

Quels budgets sont vérifiés

Chaque exécution est vérifiée par rapport à deux ensembles de limites :

• Les alertes de seuil du moniteur. Chaque alerte activée avec au-dessus de ou en dessous de et une valeur compte comme un budget : une alerte sur Largest Contentful Paint au-dessus de 2.5 devient le budget "LCP au plus 2.5 s". Ce sont les mêmes budgets que ceux affichés sur la page de résultat, voir Budgets de performance. Les alertes qui utilisent "se dégrade de (%)" n'ont pas de limite fixe et ne sont pas vérifiées.
• Chaque --budget que vous passez. Un budget est une métrique, <= ou >= et un nombre. Vous pouvez en passer jusqu'à 30.

Les métriques de temps sont en secondes, Total Blocking Time compris : tbt<=0.3 signifie 300 ms. Un budget dont la métrique n'a pas été mesurée pendant l'exécution échoue : une page qui n'a pas pu être mesurée ne passe donc jamais la vérification.

Codes de sortie et affichage

Le log affiche une ligne PASS ou FAIL par budget avec la valeur mesurée, la limite et l'origine du budget (alert ou pipeline), puis un lien vers le rapport complet. Si aucun budget n'est défini, le script l'indique et se termine avec 0.

Dans GitHub Actions, le résultat est aussi écrit dans le résumé du job : les quatre scores Lighthouse, un tableau de tous les budgets et un lien Full report.

Marqueurs de déploiement

Un marqueur est une ligne en pointillés sur les graphiques d'historique du moniteur, dans la série Déploiements. Avec --marker, le script en publie un avant de lancer l'exécution. Si le marqueur ne peut pas être publié, le script l'indique et poursuit la vérification.

Pour marquer des déploiements sans lancer de vérification, utilisez la commande sous Ou seulement marquer les déploiements dans le même panneau :

curl -X POST "https://speed.loadfocus.com/api/test/applighthouse/annotations" \
  -H "loadfocus-auth: YOUR_API_KEY" -H "content-type: application/json" \
  -d '{"label":"Deployed v1.4.2","configId":"YOUR_MONITOR_ID"}'

• label est obligatoire, jusqu'à 120 caractères.
• Omettez configId pour marquer tous les moniteurs de l'équipe.
• Ajoutez url pour relier la version.
• Ajoutez timestamp (date ISO ou epoch) pour antidater le marqueur, jusqu'à 30 jours.

Marqueurs récents dans le panneau liste les marqueurs de la période affichée, du plus récent au plus ancien. Les marqueurs publiés sans moniteur portent la mention tous les moniteurs, et Supprimer en retire un. Quand une équipe atteint 5 000 marqueurs, les plus anciens laissent la place aux nouveaux.

Comparer deux exécutions

Quand un budget est dépassé, la section Comparer les exécutions du résultat montre ce qui a changé. Choisissez une autre exécution du même moniteur dans Comparer avec et LoadFocus affiche côte à côte, avec une colonne Variation :

• Scores et Métriques
• Poids de la page, au total et par type de ressource, plus le nombre de Requêtes
• Nouvelles requêtes, Requêtes qui ont grossi et Requêtes supprimées
• Nouveaux problèmes et Corrigé depuis, les audits qui ont commencé ou cessé d'échouer

Ajoutez l'identifiant de l'autre exécution à l'adresse du résultat comme paramètre compare (par exemple &compare=12345 après le testrunid) et la page s'ouvre avec cette exécution déjà choisie, pratique pour la partager.

Connexe

• Budgets de performance
• Configuration des alertes
• Expériences Page Speed