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 !

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. »

LoĂŻc Frissard

PassionnĂ© par le web et l’entrepreneuriat, j’ai fondĂ© Digitiz en 2016. Mon objectif est de vous transmettre mon expĂ©rience et de pouvoir vous faire gagner du temps dans le choix de vos outils.

Pin It on Pinterest

Share This