Mesurer les performances de nos sites web avec LightHouse, côté client et serveur

Objectif

Quand nous développons des sites Web, nous avons à cœur de les rendre les plus légers possibles afin d’améliorer les performances pour les utilisat⋅eurs⋅rices, et aussi de réduire l'utilisation de la bande-passante pour diminuer l’énergie nécessaire à fournir ces services.

Néanmoins, il n’est pas toujours facile d’identifier quelles sont les parties à améliorer. Il existe plusieurs outils ( Ouvre une nouvelle fenêtreEcoIndex ou Ouvre une nouvelle fenêtreGreenspector pour l’impact environnemental), et nous avons retenu Lighthouse qui mesure les performances comme l'accessibilité, et que nous avons pu intégrer facilement à notre CI.

Lighthouse

Ouvre une nouvelle fenêtreLighthouse est un outil de mesure des performances d’une page Web développé par Google. Il évalue notamment : la vitesse d’affichage et de poids de page, le référencement (SEO), ainsi que l’accessibilité. Il simule la navigation comme le ferait un humain, et calcule le temps passé entre la demande du navigateur et la fin de l’affichage. Tout en évaluant le temps passé à télécharger les scripts et feuilles de style, et à exécuter le code Javascript.

On peut l’utiliser pour générer un rapport de la page que l’on souhaite (par exemple, Ouvre une nouvelle fenêtrenotre site) :

On souhaitait mesurer régulièrement les performances d’un projet afin de vérifier qu’elles ne s’éloignent pas de notre objectif, mais cela nous aurait demandé de lancer des analyses manuellement à intervalles réguliers.

Heureusement, il est possible d'automatiser ces analyses, nous allons vous présenter comment.

Intégration continue

Grâce à notre expérience avec GitLab CI, nous avons pu facilement mettre en place une tâche automatique qui lance Lighthouse :

1. un⋅e développeu⋅r⋅se modifie le code du projet
2. la personne pousse ses changements sur GitLab ouvre une demande de fusion
3. GitLab CI lance automatiquement la compilation du projet
4. ensuite, GitLab CI va faire tourner Ouvre une nouvelle fenêtreLighthouse (via Docker) sur cette version du code, puis les envoyer à Google
5. les résultats du rapport sont visibles via un lien généré par Lighthouse

Confidentialité des données et évolution dans le temps

Ces mesures sont très intéressantes, mais nous voulions améliorer 2 points :

• stocker les données dans notre infrastructure au lieu d’envoyer les données à Google
• avoir un historique pour pouvoir comparer les rapports avant et après un changement

Fort heureusement, Google fournit également le Ouvre une nouvelle fenêtre côté serveur de Lighthouse. Nous avons ainsi pu configurer notre propre instance (également via Docker).

Ainsi, GitLab CI envoie les résultats des analyses sur notre Lighthouse, ce qui ouvre de nouvelles possibilités :

• confronter les notes et mesures pour vérifier qu’une évolution ne dégrade pas les performances du site, pour ensuite faire des corrections adéquates ou expliquer au client si une diminution des performances est inévitable (par exemple, l’ajout d’une image, même optimisée, aura forcément un coût)
• constater l’évolution au fur et à mesure du temps, afin d'avoir une vue d’ensemble des performances
• les données ne sont pas transmises à Google, nous gardons le contrôle des résultats

Exemple :

Il faut prendre en compte qu’il y a une variabilité entre les résultats due aux serveurs de CI :

• Lighthouse peut être lancé par des serveurs différents, qui n’ont pas les mêmes performances
• ces serveurs peuvent être plus ou moins occupés en fonction des autres tests en cours
• il peut y avoir une congestion sur le réseau à ce moment-là (pour les appels à Strapi, qui héberge le contenu des pages)

Pour pallier cela, nous sommes en train de tester différentes solutions : restreindre Lighthouse à un seul serveur, mettre en cache les données de Strapi avant de lancer les tests pour éliminer la variabilité du réseau, etc .

Configuration de Lighthouse

Côté serveur

docker-compose.yml

On peut alors interroger ce serveur pour Ouvre une nouvelle fenêtrecréer un projet.

Dans le projet

On utilise les règles recommandées par Lighthouse et on définit quelle(s) URL(s) on souhaite utiliser :

.lighthouserc.js

Dans GitLab CI

On définit 3 valeurs de configuration via les variables de GitLab CI :

• LIGHTHOUSE_USER : utilisateur HTTP
• LIGHTHOUSE_PASSWORD : mot de passe HTTP
• LIGHTHOUSE_BUILD_TOKEN : généré quand on a créé un projet

.gitlab-ci.yml

Conculsion

L’ajout de Lighthouse à nos processus qualité nous offre un nouveau regard quantitatif sur les performances de nos projets web. C’est rapidement devenu un des indicateurs qui nous aide à améliorer nos développements au quotidien, et par conséquent les projets de nos clients.