Une bannière promotionnelle ajoutée en urgence par l’équipe marketing, chargée avec une police web supplémentaire non optimisée, a fait chuter le score de performance mobile de 92 à 61 sur la page d’accueil, sans qu’aucun développeur ne s’en aperçoive avant plusieurs jours. Le changement avait pourtant traversé la revue de code, mais personne n’avait de moyen automatique de mesurer l’impact avant la mise en production. Lighthouse CI existe précisément pour combler ce trou : lancer un audit Lighthouse à chaque pull request et faire échouer le build si un budget défini est dépassé.
Contrairement à un audit Lighthouse manuel lancé de temps en temps dans Chrome DevTools, Lighthouse CI s’intègre au pipeline d’intégration continue et compare systématiquement chaque changement à des seuils définis à l’avance.
Installer et configurer Lighthouse CI
npm install --save-dev @lhci/cli
# lighthouserc.json
{
"ci": {
"collect": {
"url": ["http://localhost:8080/", "http://localhost:8080/boutique/"],
"numberOfRuns": 3
},
"assert": {
"assertions": {
"categories:performance": ["error", { "minScore": 0.85 }],
"first-contentful-paint": ["warn", { "maxNumericValue": 2000 }],
"cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }]
}
},
"upload": {
"target": "temporary-public-storage"
}
}
}
Le paramètre numberOfRuns: 3 lance chaque page trois fois et retient la médiane, une précaution nécessaire car les métriques Lighthouse varient légèrement d’une exécution à l’autre, même sur un environnement stable.
Bloquer une pull request en cas de régression
Dans un workflow GitHub Actions, la commande lhci autorun lance la collecte puis vérifie les assertions, avec un code de sortie non nul si un seuil est dépassé :
- name: Lighthouse CI
run: |
npm run build
npx lhci autorun --config=./lighthouserc.json
Un code de sortie non nul fait automatiquement échouer le job GitHub Actions, ce qui empêche la fusion de la pull request tant que la régression n’est pas corrigée ou que le budget n’est pas sciemment ajusté par l’équipe.
Comparer contre une base plutôt qu’un score figé
Un score absolu fixé arbitrairement à 90 punit injustement une page de catalogue avec beaucoup d’images produit, structurellement plus lourde qu’une page d’accueil épurée. L’approche la plus juste consiste à définir un budget par gabarit de page, et à surveiller la tendance plutôt qu’un seuil unique universel :
- Un budget spécifique pour la page d’accueil, plus stricte car première impression
- Un budget distinct, plus tolérant, pour les pages produit riches en images
- Une alerte sur toute variation de plus de 5 points entre deux exécutions consécutives, même sans franchir de seuil absolu
Ce que Lighthouse CI ne remplace pas
Les métriques Lighthouse sont mesurées en laboratoire, sur un environnement contrôlé, ce qui les distingue des données de terrain issues des vrais visiteurs (Core Web Vitals réels, remontés via le Chrome User Experience Report). Un score Lighthouse excellent en CI n’exclut pas des soucis de performance réels sur des connexions mobiles lentes ou des appareils bas de gamme sous-représentés dans les tests de laboratoire.
En résumé
Lighthouse CI transforme la performance d’un ressenti subjectif en un budget vérifiable automatiquement à chaque pull request, avant que la régression n’atteigne les visiteurs réels. Les techniques concrètes pour faire remonter un score dégradé — lazy-loading, préchargement de police, réduction du JavaScript — relèvent d’un travail d’optimisation distinct de la seule mise en place de la mesure.
