Lighthouse CI : un historique de nos mesures à chaque déploiement

Nous avons publié la définition de notre éco-budget : des pages de moins de 1 024 Ko, avec moins de 40 requêtes et moins de 600 éléments dans le DOM. L’article promettait d’expliquer plus tard « comment intégrer ces indicateurs dans votre processus d’intégration continue ». Voici cette explication, avec quelques ajustements.

Ce que faisait notre première étape Lighthouse

Notre déploiement lançait déjà Lighthouse, l’outil d’audit de Google intégré à Chrome. L’étape répondait par oui ou par non : la page respecte le budget, ou elle ne le respecte pas. Nous y avions mis des seuils de temps de chargement, vite retirés parce qu’ils faisaient échouer des déploiements au hasard. La base de données des résultats était rangée dans le dépôt du site, à côté du code, et l’étape a fini par disparaître du workflow.

Un oui ou non ne dit rien de la pente. Une page qui passe de 150 à 290 Kio en six mois respecte toujours un budget de 500 Kio. Personne ne le remarque avant le jour où elle le dépasse, et ce jour-là, il faut retrouver lequel des cinquante derniers déploiements a commencé à l’alourdir.

Un serveur qui garde chaque mesure

Lighthouse CI (LHCI) est l’outil d’intégration continue publié par l’équipe Chrome. Il lance Lighthouse, vérifie des seuils, et peut envoyer les rapports à un serveur qui les conserve et les affiche en courbes, déploiement par déploiement.

Chez nous, chaque push déroule désormais quatre étapes :

1. Le site est construit et envoyé chez notre hébergeur, comme avant
2. Une fois le site en ligne, Lighthouse mesure six pages, trois fois chacune : l’accueil, les réalisations, les expertises, l’outil d’audit, la liste des articles et un article illustré
3. Les rapports partent sur le serveur LHCI
4. Le budget est vérifié, et s’il est dépassé, un message arrive dans notre canal Slack

Un dépassement ne bloque pas la mise en ligne. Nous mesurons le site réel, avec la compression et les en-têtes de cache de l’hébergeur, ce qui oblige à mesurer après le déploiement : quand l’alerte tombe, la page est déjà en ligne. Bloquer le job à ce moment-là ne corrigerait rien.

Notre préproduction et la production envoient leurs rapports au même projet, chacune sur sa branche. Le serveur compare chaque page de préproduction à la même page en production, ce qui permet de voir une régression avant qu’elle ne parte chez les visiteurs.

Gratuit, avec une contrepartie

Un serveur d’historique a besoin d’un endroit où garder ses données dans la durée. Les offres gratuites ne le permettent pas toutes. Chez Render, que nous utilisons déjà, un service gratuit n’a pas de disque persistant, et la base Postgres gratuite expire au bout de 30 jours. Nous avons donc séparé les deux : le serveur tourne sur l’offre gratuite de Render, les données sont stockées dans une base Postgres gratuite chez Neon, permanente et limitée à 0,5 Go.

En contrepartie, Render endort le serveur après 15 minutes sans visite, et il met environ une minute à se réveiller. Notre workflow commence donc par l’appeler en boucle jusqu’à ce qu’il réponde. Une minute de plus sur un déploiement, c’est un prix que nous acceptons pour un serveur qui ne coûte rien et ne tourne pas quand personne ne s’en sert.

Notre budget

Notre éco-budget annonçait 1 024 Ko par page. En septembre 2026, notre page la plus lourde en transfère 302. Garder 1 024 aurait laissé une page tripler sans la moindre alerte, alors nous l’avons ramené à 500 Kio. Les seuils par type de ressource servent à attraper les erreurs courantes : une bannière oubliée en pleine résolution, une police ajoutée pour essayer, un script de suivi installé en passant. Le plafond de 40 requêtes vient de l’éco-budget d’origine et reste large. Celui des requêtes vers d’autres domaines est serré exprès : nous voulons décider de chaque nouveau service externe, et non le découvrir dans un rapport. Enfin, 600 éléments au plus dans le DOM : chaque élément est du travail pour le navigateur, à l’affichage comme à chaque interaction.

Deux précisions sur les chiffres. Lighthouse compte en kibioctets de 1 024 octets, là où la pastille de poids en bas de nos pages compte en kilo-octets de 1 000, comme Chrome. Et Lighthouse simule un téléphone : il reçoit les images prévues pour un petit écran, plus légères que celles d’un ordinateur.

Suivi dans l’historique, sans seuil

Les temps de chargement et les scores sont enregistrés à chaque déploiement, sans seuil. Les machines de GitHub Actions sont partagées : d’un passage à l’autre, les temps varient sans que le site ait changé. Sur ces indicateurs, une tendance sur vingt déploiements est plus parlante qu’une mesure isolée.

assert: {
	assertions: {
		'resource-summary:total:size': ['error', { maxNumericValue: 500 * 1024 }],
		'resource-summary:image:size': ['error', { maxNumericValue: 300 * 1024 }],
		'resource-summary:font:size': ['error', { maxNumericValue: 100 * 1024 }],
		'resource-summary:script:size': ['error', { maxNumericValue: 100 * 1024 }],
		'resource-summary:total:count': ['error', { maxNumericValue: 40 }],
		'resource-summary:third-party:count': ['error', { maxNumericValue: 5 }],
		'dom-size': ['error', { maxNumericValue: 600 }],
	},
},

npx @lhci/cli collect   # six pages, trois passages chacune
npx @lhci/cli upload    # envoi au serveur, même si le budget est dépassé
npx @lhci/cli assert    # vérification du budget, alerte Slack si dépassement

Le premier comparatif

L’image en tête d’article est le premier comparatif que nous avons obtenu, sur un serveur de test pendant la mise au point : la page d’accueil de la préproduction face à celle de la production. Performance, accessibilité et bonnes pratiques ne bougent pas. Le SEO perd 31 points, et c’est voulu : notre préproduction publie un fichier robots.txt qui interdit l’indexation, pour que les moteurs de recherche ne la confondent pas avec le site public. Lighthouse le détecte et le sanctionne.

Le même écran annonce 410 millisecondes de plus pour l’affichage du plus grand élément de la page en préproduction. Nous n’en tirons rien pour l’instant : chaque page n’avait été mesurée qu’une fois, et c’est pour ne plus juger sur une mesure isolée que nous avons mis ce serveur en place.

Mesurer sans alourdir

Restait le poids des mesures elles-mêmes. Pour notre accueil, un rapport Lighthouse brut pèse 687 Kio, dont 420 Kio de captures d’écran encodées en texte. Nous les avons désactivées : le rapport descend à 265 Kio, et en moyenne à 62 Kio une fois stocké, parce que Postgres compresse les gros champs de texte. Les captures d’écran, elles, se compressent très mal.

Un déploiement complet, six pages mesurées trois fois, occupe ainsi environ 1,3 Mio. Les mesures de la préproduction sont effacées au bout de 90 jours, celles de la production sont conservées. À notre rythme de 2026, entre 12 et 26 déploiements par mois selon les périodes, les 0,5 Go de la base gratuite tiennent plusieurs années.

La suite

Les assertions nous laissent de la place pour la suite : un plancher pour le score d’accessibilité, puis des seuils par gabarit de page, puisque le blog porte plus d’images que les pages d’offre. Nous les fixerons après quelques semaines d’historique, pour les régler sur des courbes plutôt que sur une seule mesure.

Transparence : comment cet article a été produit

Nous utilisons l’intelligence artificielle dans notre travail éditorial, et nous préférons le dire clairement.

Pour cet article, elle nous a accompagnés dans la rédaction.

Les chiffres cités viennent de notre propre installation : nos seuils, nos mesures et le premier comparatif entre la préproduction et la production. L’image en tête d’article est une vraie capture d’écran de ce comparatif.