Pourquoi améliorer uniquement votre score Lighthouse ne garantit pas un site Web rapide

En résumé...

« Fier de votre score Lighthouse de 100 % ? C’est mérité !

Cependant, gardez à l’esprit que cela ne vous donne qu’un aperçu partiel des performances de votre site. Explorez les différences entre les mesures de Lighthouse et d’autres outils, comprenez leur impact sur les indicateurs de performance, et découvrez pourquoi le suivi des utilisateurs réels est essentiel pour une vision complète. »

Google Lighthouse de La FOSSE

Optimiser la vitesse...

Ce moment est familier à tout le monde : vous travaillez à optimiser la vitesse de chargement d’un site, en veillant à chaque milliseconde. Pour mesurer les performances, vous utilisez Google Lighthouse dans les outils de développement de Chrome, un choix courant pour évaluer les améliorations de rapidité.

Performance Lighthouse de La FOSSE

Après avoir généré des dizaines de rapports et appliqué toutes les recommandations, vous obtenez enfin un score parfait de 100 % sur Google Lighthouse ! C’est gratifiant, bien sûr, et vous pourriez même envisager de le mentionner dans une demande d’augmentation. Toutefois, ne vous fiez pas uniquement à ce score. Google Lighthouse est un bon indicateur de certaines améliorations, mais il ne reflète pas toute la réalité des performances du site pour les utilisateurs réels. Il s’agit d’un outil parmi d’autres, offrant une perspective incomplète.

Comme vous pouvez voir, même certains de ces grands noms de ce monde n’atteignent pas la perfection.

Pour lancer un rapport avec Lighthouse, ouvrez DevTools, accédez à l’onglet Lighthouse et générez le rapport ! Il est possible de configurer Lighthouse pour des tests sur des connexions lentes ou de créer des rapports distincts pour mobiles et ordinateurs. Intégré dans Chrome et l’outil PageSpeed Insights de Google, il produit des résultats en un temps record : seulement 10 à 15 secondes. Cependant, bien que Lighthouse soit pratique et rapide, il n’offre pas une vision complète des performances réelles et peut différer des résultats d’autres outils.

 

Cela ne reflète pas l’expérience des « utilisateurs réels ».

Dans Capital Web Performance, toutes les données ne sont pas équivalentes. Les rapports de Lighthouse s’appuient sur des données simulées ou synthétiques, obtenues grâce à des hypothèses. Cette approche permet à Lighthouse d’être rapide. Par exemple, en limitant la vitesse de connexion dans Lighthouse, vous pouvez tester des conditions de navigation lente ou rapide. Par défaut, Lighthouse utilise une connexion rapide, mais il peut être ajusté pour simuler des chargements plus lents, bien que cela reste une estimation de la performance sur une connexion différente.

Une fois de plus, l’environnement de test est une simulation, pas une représentation fidèle de la réalité. Les conditions de limitation utilisées ne correspondent probablement pas aux vitesses de connexion réelles d’un utilisateur moyen sur le site, car celui-ci pourrait disposer d’une connexion plus rapide ou d’un processeur plus lent. Ce que propose Lighthouse se rapproche davantage d’un test instantané et simplifié.

Les données simulées sont utiles pour réaliser des tests rapides dans des conditions optimisées, mais elles sacrifient la précision en supposant certaines vitesses de connexion et en faisant des moyennes qui peuvent s’éloigner de la réalité des utilisateurs.

Bien que la limitation simulée soit le réglage par défaut dans Lighthouse, il est également possible d’appliquer des méthodes de limitation plus proches des conditions réelles. Ces tests prendront plus de temps mais fourniront des résultats plus exacts. Pour obtenir des tests plus réalistes avec Lighthouse, il est recommandé d’utiliser des outils en ligne tels que DebugBear ou WebPageTest.

 

Cela n’affecte en rien les scores des Core Web Vitals.

Les Core Web Vitals, dont tout le monde parle, sont les critères de performance standard définis par Google. Ils vont bien au-delà d’un simple rapport du type « Votre page s’est chargée en X secondes » en analysant une série de détails plus fins qui permettent de mieux comprendre comment la page se charge, quelles ressources bloquent d’autres éléments, l’impact des interactions lentes des utilisateurs, ainsi que la manière dont la page se déplace en fonction du chargement des ressources et du contenu. Zeunert propose un excellent article à ce sujet sur Smashing Magazine, qui explique chaque indicateur en détail.

L’idée principale ici est que les données simulées générées par Lighthouse peuvent être différentes (et c’est souvent le cas) des mesures obtenues avec d’autres outils de performance. J’ai pris le temps d’expliquer cela en profondeur dans un autre article. Ce qu’il faut retenir, c’est que les scores de Lighthouse n’affectent pas les données des Core Web Vitals. La raison en est que les Core Web Vitals reposent sur des données collectées à partir des utilisateurs réels, extraites du rapport Chrome User Experience (CrUX), qui est mis à jour chaque mois. Bien que les données CrUX aient une certaine limite temporelle, elles offrent une vue plus fidèle du comportement réel des utilisateurs et des conditions de navigation, contrairement aux données simulées dans Lighthouse.

Le point crucial que je souhaite souligner, c’est que Lighthouse n’est tout simplement pas adapté pour mesurer précisément les indicateurs des Core Web Vitals.

J’ai mis en avant l’essentiel : dans la réalité, les utilisateurs vivent des expériences variées sur une même page. Ce n’est pas comme si vous visitiez un site, le laissiez se charger, puis le fermiez sans rien faire. En réalité, vous êtes bien plus susceptible d’interagir avec la page. Or, pour mesurer certains indicateurs Core Web Vitals, comme l’INP (Interaction to Next Paint), qui évalue la lenteur de la peinture après une interaction de l’utilisateur, Lighthouse ne peut tout simplement pas mesurer cela !

C’est pareil pour des indicateurs comme le Cumulative Layout Shift (CLS), qui évalue la « stabilité visuelle » de la mise en page. Les changements de mise en page surviennent souvent plus bas sur la page après que l’utilisateur a fait défiler le contenu. Si Lighthouse utilisait les données CrUX (ce qui n’est pas le cas), il pourrait alors se baser sur des données réelles provenant d’utilisateurs qui interagissent avec la page et rencontrent des problèmes de CLS. Mais, étant donné que Lighthouse se contente d’attendre que la page soit entièrement chargée sans jamais interagir avec son contenu, il ne peut en aucun cas détecter de changements de mise en page ou évaluer le CLS.

 

Mais cela reste un « bon point de départ ».

Voici ce que je souhaite que vous reteniez au final : un rapport Lighthouse est très utile pour générer rapidement des résultats, grâce aux données simulées qu’il utilise. En ce sens, on peut considérer Lighthouse comme un « test pratique » et même une première étape pour repérer des opportunités d’optimisation des performances.

Cependant, cela ne donne qu’une vision partielle. Pour obtenir une vue plus complète, il est nécessaire d’utiliser un outil qui se base sur des données réelles provenant des utilisateurs. Les outils qui exploitent les données CrUX sont bons pour cela, mais encore une fois, ces données sont mises à jour une fois par mois (plus précisément, tous les 28 jours), ce qui peut ne pas refléter les comportements et interactions les plus récents des utilisateurs. Bien que ces données soient actualisées quotidiennement et qu’il soit possible d’examiner des enregistrements historiques pour obtenir des échantillons plus larges, elles ne sont pas en temps réel.

Le mieux reste d’utiliser un outil qui suit les utilisateurs en temps réel.
Si vous voulez une image globale des performances de votre site, n’hésitez pas à utiliser Lighthouse, mais ne vous arrêtez pas là, car vous n’obtiendrez qu’une vue partielle. Vous devrez approfondir vos analyses et examiner les performances avec une surveillance des utilisateurs réels pour obtenir une évaluation plus complète et plus précise.

Vous désirez en discuter avec nous?