Comment obtenir un score de 100/100 sur Google Lighthouse ? Instrument de mesure, d’analyse et de satisfaction, le nouvel outil google est de plus en plus utilisé dans le but d’analyser les performances réelles d’un site web.
Romain Rissoan, créateur d’optédif Formation, a récemment mis au point une approche pratique et éprouvée afin d’atteindre ce fameux score de 100, et ce en se calquant notamment sur l’analyse de Polly Pospelova (responsable de la recherche chez Delete).
Le fondateur nous livre aujourd’hui ses astuces et ses secrets !
Sommaire
Qu’est-ce que Google Lighthouse ?
Si l’on se fit à la description Made in Google, Lighthouse est un outil open source et automatisé pour améliorer la qualité des pages Web. Il est également possible d’exécuter Lighthouse sur n’importe quelle page publique, ou nécessitant une authentification.
Au niveau de ses fonctionnalités spécifiques, Lighthouse permet d’auditer :
- La performance
- L’accessibilité
- Les applications Web progressives
- Les meilleures pratiques
- Le SEO
- … et plus encore !
Ainsi, une fois que Lighthouse a exécuté ses audits sur la page que vous avez choisie, il générera un rapport pour vous.
Bon à savoir : la description officielle de Google indique également que Lighthouse peut être exécuté dans Chrome DevTools, à partir d’une extension Chrome, du site Web PageSpeed Insights, de la ligne de commande ou en tant que module Node.
Comment profiter de Google Lighthouse ?
En pratique, Le rapport créé par Lighthouse vous fournit des recommandations et des opportunités d’optimisation. Il vous donnera également des exemples de domaines afin d’optimiser vos recherches : ceci correspond à la recommandation « opportunité ».
Parallèlement, chaque audit dispose d’un document de référence expliquant les résultats, ainsi que des conseils sur ce que vous pouvez faire pour résoudre les problèmes que Google Lighthouse met en évidence.
En résumé, la première valeur ajoutée de Lighthouse est de nous aider à surveiller efficacement la qualité d’un site Web, tout en indiquant de manière pratique ce qui doit être corrigé.
Les grandes marques obtiennent-elles 100/100 sur Lighthouse ?
Aussi, vous pensez peut-être que seuls les petits sites peuvent vraiment bénéficier des audits de Lighthouse ? et que les grandes marques leaders avec des sites grands et puissants obtiendraient toutes de bons résultats, sans exception – la réalité est assez différente et il existe de nombreuses grandes entreprises avec des sites à faible score.
Exemple :
ASOS – la fameuse marque de vente au détail britannique, affichant un chiffre d’affaires annuel de 2,5 milliards de livres sterling, n’obtient actuellement que 19/100 pour sa performance. Ceci n’est qu’un exemple des nombreux grands noms qui ne répondent actuellement pas aux critères Google Lighthouse. En regardant plus loin, il existe des entreprises du secteur du référencement, voire même des fournisseurs d’outils spécialisés de référencement / SEM, qui n’obtiennent actuellement qu’un score très faible dans Lighthouse.
Bien que cela puisse vous surprendre, il existe en réalité de nombreuses explications contribuant à ces manquements : principalement, il faut ici savoir que l’algorithme Lighthouse change très régulièrement. En ce sens, ces mutations peuvent avoir des conséquences notables, faisant passer un site d’une note excellence à une note médiocre !
Comment améliorer son score sur Google Lighthouse ?
En analysant sur le long terme la notation de son site internet Optédif Formation, Romain Rissoan a synthétisé l’ensemble des rapports Lighthouse afin d’élaborer une liste d’amélioration. Le but ? Vous aider à optimiser votre site en continu, à récupérer si besoin est votre score de 100/100 sur Lighthouse.
Les points d’amélioration :
- HTTP/2
- Qualité d’image (WebP et autres)
- JS moderne et rejet des bibliothèques lourdes
- Auto-critique
- Petits morceaux « chargez uniquement ce dont vous avez besoin »
- Chargeur de morceaux semi-automatique
Ceci étant dit, nous allons maintenant vous présenter chaque point d’amélioration dans le détail, sur la base des conclusions des rapports Lighthouse.
Migration de HTTP/1 vers HTTP/2
Dans un premier temps, il va vous falloir migrer : de HTTP/1 vers HTTP/2 !
Si vous débutez dans ce domaine, HTTP signifie HyperText Transfer Protocol. Le protocole est utilisé pour la communication entre les ordinateurs clients et les serveurs Web par l’envoi et la réception de requêtes HTTP et de réponses HTTP.
HTTP/2 a été développé à l’origine par Google et a été conçu pour réduire la latence afin d’améliorer la vitesse de chargement des pages dans les navigateurs Web.
Cependant, l’une des principales limitations de HTTP/2 est que pour chaque requête, un navigateur établit une connexion, quelle que soit la taille de chaque ressource (image, script, css, vidéo, etc. .). Le processus prend souvent plus de temps que le transfert des données lui-même.
Les navigateurs peuvent envoyer 6 requêtes à la fois. Certains propriétaires de sites Web créent ainsi des CDN (réseaux de diffusion de contenu) pour aider à surmonter cette limitation.
Vous devez cependant garder à l’esprit que l’activation de HTTP/2 seul n’améliore pas les performances. Il vous permet surtout d’implémenter certaines améliorations qui ne seraient pas aussi efficaces avec HTTP/1.
Avec HTTP/2, un navigateur établit une connexion avec un serveur une fois et envoie toutes les requêtes au sein de la même connexion. En tant que tel, il y a d’énormes économies de temps.
Le mot de Romain : « Considérez cela comme une course, où 100 concurrents veulent participer. Ce que vous auriez avec la course de HTTP/1, c’est que seuls six athlètes sont autorisés à courir à la fois. Alors que dans la course de HTTP/2, tous les 100 peuvent courir en même temps ».
Amélioration de la qualité des images
Parallèlement, nous avons réalisé qu’il y avait beaucoup de choses à faire pour gagner un temps considérable en améliorant la qualité de l’image sur site :
- Différer les images hors écran : la plupart des sites Web ont le même balisage HTML universel, et la visibilité des images est gérée avec CSS et JS. Nous avons constaté que le report des images hors écran pourrait améliorer les performances du site. Il convient donc d’organiser et de différencier l’affichage des images entre une vue bureau (chargement 4 images) et une vue tablette par exemple (1 seule image). En différenciant l’affichage en fonction des supports, nous avons calculé que nous pouvions économiser 2,61 secondes de chargement !
- Publier des images dans des formats de nouvelle génération : nous avons constaté que les nouveaux formats d’image tels que WebP peuvent fournir une meilleure compression qu’un PNG ou un JPEG. Ainsi, on obtient des téléchargements plus rapides, moins de consommation de données, et donc un site plus rapide.
- Utiliser des images correctement dimensionnées : pour cette amélioration, nous avons déployé une approche appelée « taille d’image adaptative ». Pour ce faire, il va falloir remplacer vos anciennes images individuelles par des « ensembles SRC ». Résultat ? Un choix de taille d’images différente. Pour que la taille d’images de votre ensemble SRC soit la plus optimisée possible, vous pouvez la calculer à partir de Google Analytics en utilisant ; Audience > Technologie > Navigateurs et système d’exploitation > Résolution d’écran.
- Utiliser le chargement « paresseux » : Nous avons enfin compris qu’une autre façon d’apporter des améliorations était de ne charger les images que lorsqu’elles entrent dans la fenêtre de l’utilisateur, et pas avant ! Cela peut être fait avec des scripts complexes et un balisage HTML, ainsi qu’en surveillant les événements de défilement ou de redimensionnement.
Utiliser une approche critique de JS et CSS
Nous savons qu’un navigateur ne commence pas à afficher une page tant qu’il n’a pas chargé et analysé toutes les ressources. Plus précisément, il charge le HTML, l’analyse, trouve les ressources externes (JS, CSS), les met en file d’attente, les télécharge, les analyse, les évalue et ensuite seulement, génère la page.
Le mot de Romain : « Ce que nous avons réalisé, c’est que cela pose un problème pour les sites Web avec de gros fichiers JS et CSS uniques – fondamentalement, le processus d’analyse et d’évaluation prend beaucoup de temps. Cela signifie également que l’utilisateur doit attendre la fin de ce processus avant que le contenu commence à se charger. Ces problèmes étaient quelque chose que nous devions rectifier ».
Les corrections :
- Le premier chargement : nous avons ici vérifié si le navigateur demandait une page pour la première fois. Si tel était le cas, nous ne prenons alors que les ressources nécessaires (JS, CSS) pour une page, et les intégrons dans le balisage HTML et dans la balise HEAD. Ensuite, lorsque le navigateur reçoit le code HTML, il obtient toutes les ressources nécessaires et les analyse en un seul processus. Cela permet au navigateur d’afficher le contenu de la page aux utilisateurs presque instantanément. Une fois le balisage en ligne chargé sur la première page, nous avons ensuite chargé toutes les ressources standard nécessaires en arrière-plan et les avons mises en cache.
- Charges ultérieures : Nous avons ensuite vérifié si le navigateur avait déjà les ressources mises en cache avant de sauter l’inlining. Ainsi, au lieu d’utiliser des ressources critiques intégrées, la page utilise plutôt des ressources mises en cache. En conséquence, le contenu s’est chargé instantanément lors du premier chargement, et lors de tous les chargements suivants. Ainsi, tout le texte significatif s’affiche à partir du deuxième cadre, permettant aux utilisateurs de lire le contenu presque instantanément.
- Solution automatisée : enfin, nous avons également créé des cookies anonymes comme marqueurs pour la ressource déjà chargée. Ainsi, lorsqu’une page se charge, nous vérifiions si le navigateur dispose déjà de nos cookies de ressources afin de déterminer si nous devions envoyer des ressources en ligne ou les prendre dans le cache. Il s’agit d’une solution brillamment simple qui nous a permis de charger le site Web presque instantanément lors des premiers chargements (ainsi que pour les chargements répétés), et ce même sur des connexions 3G lentes.
Chargez ce que vous avez besoin
Au lieu d’avoir un gros fichier CSS ou JS, divisez tous les CSS et JS en petits morceaux ,pour chaque bloc logique du site Web. Cela comprend des aspects tels que les formulaires, les en-têtes, les pieds de page, etc.
Cette approche a également été complétée par HTTP/2, car nous avons chargé de nombreuses « petites ressources » en une seule connexion, rapidement et sans latence.
Le mot de Romain : « Pour en revenir à mon analogie avec la course, non seulement nous avons permis à nos 100 athlètes de courir en même temps, mais nous avons également raccourci leur piste ».
Chargement semi-automatique
Encore une fois, il serait assez laborieux de le faire manuellement, alors nous avons trouvé une solution pour semi-automatiser ce processus et, ainsi vous faciliter la vie.
Nous avons réalisé que les développeurs frontend n’avaient qu’à déclarer les noms des ressources dont ils ont besoin pour chaque composant, à l’intérieur même du balisage des composants.
Ensuite, lorsqu’une page se charge, tous les composants utilisés sont ensuite combinés et automatiquement transformés sur le serveur dans le bon format pour la mise en page finale.
Utiliser le JS moderne et rejeter les bibliothèques lourdes
Une autre conclusion a été d’utiliser JS moderne, qui est un nouveau format pris en charge par tous les navigateurs modernes. Une taille de fichier JS moderne est 20% plus légère. Elle ne contient aucun code nécessaire à la compatibilité avec les anciens navigateurs.Ainsi, nous sommes simplement passés au JS moderne avec un retour automatique à l’ancien JS pour les navigateurs plus anciens : les résultats parlent d’eux-mêmes :
133 millisecondes contre 41 millisecondes avec le JS moderne.
Le dernier mot de Romain : « En espérant que vous avez trouvé cet examen de présentation utile et que vous avez pu constater les mesures que nous avons prises pour amener notre score là où il est aujourd’hui. »