Vérifier la performance « à la main » avant une mise en production revient, dans la plupart des équipes, à lancer un test PageSpeed Insights la veille du déploiement, à regarder le score, et à l’oublier dès que la fonctionnalité suivante arrive. Le problème n’est pas la vérification elle-même, c’est son caractère irrégulier : une régression introduite un mardi peut très bien passer inaperçue jusqu’à ce qu’un visiteur ou, pire, Google Search Console la signale des semaines plus tard.
Sur un site vitrine à fort trafic organique, l’équipe a choisi d’automatiser entièrement cette vérification en intégrant Lighthouse CI directement dans le pipeline GitHub Actions, avec un principe simple : toute pull request qui fait chuter le LCP mesuré au-delà d’un seuil défini ne peut pas être fusionnée sans une validation explicite.
Pourquoi un score Lighthouse global ne suffit pas
Le score Lighthouse agrège plusieurs métriques en une seule note sur 100, ce qui le rend pratique pour un coup d’œil rapide mais dangereux comme critère de blocage automatique : un score qui passe de 92 à 88 peut cacher une régression sérieuse sur une seule métrique compensée par une amélioration ailleurs. Le pipeline mis en place ici n’utilise donc pas le score global comme critère, mais des assertions sur des métriques précises : LCP, CLS et Total Blocking Time, chacune avec son propre seuil.
Où faire tourner Lighthouse dans le pipeline
Faire tourner Lighthouse contre l’environnement de production directement poserait un problème évident de contamination des données analytiques et de risque en cas de bug. Le choix a été de déployer chaque pull request sur un environnement de staging éphémère, avec les mêmes ressources serveur que la production (même configuration PHP-FPM, même cache d’objet Redis), pour que les mesures restent comparables d’une exécution à l’autre.
Ce point est souvent sous-estimé : Lighthouse est sensible aux ressources de la machine qui l’exécute. Faire tourner le job sur un runner GitHub Actions standard, partagé avec d’autres jobs concurrents, introduit une variance qui peut fausser les résultats de plusieurs points de LCP d’une exécution à l’autre.
Moyenner plusieurs exécutions
Pour limiter cette variance, la configuration Lighthouse CI (lighthouserc.json) demande trois exécutions consécutives par URL testée et retient la médiane, plutôt qu’une seule mesure isolée qui pourrait être un artefact.
{
"ci": {
"collect": {
"url": [
"https://staging-pr-123.example.com/",
"https://staging-pr-123.example.com/produit/exemple/"
],
"numberOfRuns": 3
},
"assert": {
"assertions": {
"largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
"cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }],
"total-blocking-time": ["warn", { "maxNumericValue": 300 }]
}
},
"upload": {
"target": "temporary-public-storage"
}
}
}
Le job GitHub Actions
Le job attend que le déploiement de staging soit terminé (via une dépendance sur le job précédent) avant de lancer Lighthouse CI. Une régression sur le LCP ou le CLS fait échouer le job avec le statut error, ce qui bloque la fusion si la branche protégée exige que tous les checks passent ; une régression sur le TBT ne fait qu’avertir, sans bloquer, car cette métrique est jugée moins critique sur ce projet.
jobs:
lighthouse:
needs: deploy-staging
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run Lighthouse CI
run: |
npm install -g @lhci/cli@0.13.x
lhci autorun --config=./lighthouserc.json
Gérer les faux positifs
Les premières semaines ont fait remonter des faux positifs liés à des appels réseau tiers instables (un widget d’avis clients hébergé ailleurs, ponctuellement lent). Plutôt que de baisser les seuils pour faire taire ces alertes, l’équipe a préféré bloquer les domaines tiers non essentiels pendant les runs Lighthouse, via l’option blockedUrlPatterns, pour ne mesurer que ce qui dépend réellement du code du site.
- Assertions sur des métriques précises plutôt que sur un score agrégé.
- Moyenne ou médiane de plusieurs exécutions pour absorber la variance des runners.
- Blocage des ressources tierces non essentielles pour ne pas polluer la mesure.
Ce que ce pipeline ne couvre pas
Cette mise en place ne dit rien sur la manière de fixer les seuils eux-mêmes, question de méthode et d’arbitrage produit traitée ailleurs. Elle ne remplace pas non plus une supervision terrain (RUM) des visiteurs réels : Lighthouse mesure un scénario de laboratoire, reproductible et comparable dans le temps, mais toujours différent des conditions réseau et matérielles réelles des visiteurs.
Un budget de performance qui dépend de la mémoire d’un développeur n’est pas un budget, c’est une intention. Un pipeline qui bloque automatiquement est le seul mécanisme qui tient dans la durée.
Notre verdict
L’intégration a demandé environ deux jours de mise en place, principalement pour stabiliser l’environnement de staging et calibrer les seuils sans provoquer trop de faux positifs au démarrage. Depuis sa mise en place, deux régressions de LCP ont été bloquées avant fusion, l’une causée par l’ajout non différé d’un script de suivi marketing, l’autre par une police web chargée en synchrone. Dans les deux cas, la revue de code seule n’aurait probablement pas suffi à les repérer.
