Pourquoi optimiser votre score Lighthouse ne suffit pas pour un site Web rapide

Nous avons tous vécu ce moment. Vous optimisez les performances d’un site Web, en scrutant chaque milliseconde nécessaire au chargement de la page actuelle. Vous avez lancé Google Lighthouse à partir des DevTools de Chrome, car tout le monde et leur oncle l’utilisent pour évaluer les performances.

Après avoir exécuté votre 151e rapport et effectué toutes les améliorations recommandées, vous découvrez le nirvana : un score de performance parfait à 100 % !

Il est temps de vous féliciter pour un travail bien fait. Peut-être que vous pourrez l’utiliser pour obtenir l’augmentation de salaire que vous souhaitiez ! Sauf que ne le faites pas – du moins, n’utilisez pas Google Lighthouse comme seule preuve. Je sais qu’un score parfait produit toutes sortes de bons sentiments. Après tout, c’est ce que nous visons !

Google Lighthouse est simplement un outil dans une boîte à outils de performance complète. Ce qu’il ne s’agit pas, c’est d’une image complète des performances de votre site Web dans le monde réel. Bien sûr, nous pouvons obtenir de nombreuses informations sur les performances d’un site et même repérer les problèmes qui doivent être résolus pour accélérer les choses. Mais encore une fois, c’est une image incomplète.

Pourquoi Google Lighthouse est excellent

J’entends d’autres développeurs se vanter de scores Lighthouse parfaits et je vois les captures d’écran publiées sur les réseaux sociaux. Hé, je viens de le faire moi-même dans l’introduction de cet article !

Lighthouse est peut-être l’outil de reporting sur les performances Web le plus utilisé. Je parierais que son omniprésence est davantage due à la commodité qu’à la qualité de ses rapports.

Ouvrez DevTools, cliquez sur l’onglet Lighthouse et générez le rapport ! Il existe même de nombreuses façons de configurer Lighthouse pour mesurer les performances dans des situations simulées, telles que des vitesses de connexion Internet lentes ou la création de rapports distincts pour mobile et ordinateur de bureau. C’est un outil très puissant pour quelque chose qui est intégré à un navigateur gratuit. C’est aussi intégré directement dans l’outil PageSpeed ​​​​Insights de Google!

Et c’est rapide. Exécutez un rapport dans Lighthouse et vous obtiendrez quelque chose en 10 à 15 secondes environ. Essayez de générer des rapports avec d’autres outils et vous vous retrouverez à remplir votre café, à aller aux toilettes et peut-être à consulter vos e-mails (dans un ordre variable) en attendant les résultats. Il y a une bonne raison à cela, mais tout ce que je veux souligner, c’est que Google Lighthouse est foudre rapide en ce qui concerne les rapports sur les performances.

Pour récapituler : Lighthouse est génial dans beaucoup de choses !

• C’est pratique d’y accéder,
• Il fournit de nombreuses configurations pour différents niveaux de dépannage,
• Et il crache des rapports en un temps record.

Et qu’en est-il de cette partition verte animée et lumineuse – qui n’aime pas ça ?!

OK, c’est le côté rose des rapports Lighthouse. Il est juste de souligner également ses limites. Il ne s’agit pas de vous dissuader, vous ou quelqu’un d’autre, d’utiliser Lighthouse, mais plutôt de vous avertir que votre score peut ne pas refléter parfaitement la réalité – ou même correspondre aux scores que vous obtiendriez dans d’autres outils, y compris celui de Google. Informations sur la vitesse de page.

Cela ne correspond pas aux « vrais » utilisateurs

Toutes les données ne sont pas créées égales en termes de performance Web capitale. Il est important de le savoir, car les données représentent des hypothèses formulées par les outils de reporting lors de l’évaluation des mesures de performances.

Les données sur lesquelles Lighthouse s’appuie pour ses rapports s’appellent données simulées. Vous avez peut-être déjà une bonne idée de ce que cela signifie : c’est synthétique données. Maintenant, avant de donner un coup de pied aux données simulées parce qu’elles ne sont pas des données « réelles », sachez que c’est la raison pour laquelle Lighthouse est ultra rapide.

Vous savez qu’il existe un paramètre permettant de « limiter » la vitesse de la connexion Internet ? Cela simule différentes conditions qui ralentissent ou accélèrent la vitesse de connexion, quelque chose que vous configurez directement dans Lighthouse. Par défaut, Lighthouse collecte des données sur une connexion rapide, mais nous pouvons la configurer sur quelque chose de plus lent pour obtenir des informations sur les chargements de pages lents. Mais attention ! Lighthouse estime ensuite à quelle vitesse la page se serait chargée sur une connexion différente.

DébogageOurs fondateur Matt Zeunert grandes lignes comment les données s’exécutent dans un environnement de limitation simuléexpliquant comment Lighthouse utilise des moyennes « optimistes » et « pessimistes » pour tirer des conclusions :

« [Simulated throttling] réduit la variabilité entre les tests. Mais s’il existe une seule requête lente bloquant le rendu qui partage une origine avec plusieurs réponses rapides, Lighthouse sous-estimera le temps de chargement de la page.

Lighthouse fait la moyenne d’estimations optimistes et pessimistes lorsqu’il ne sait pas exactement quels nœuds bloquent le rendu. En pratique, les mesures peuvent être plus proches de l’une ou l’autre de ces valeurs, selon le graphique de dépendance le plus correct.

Et encore une fois, l’environnement est une configuration et non une réalité. Il est peu probable que vos conditions de limitation correspondent aux vitesses de connexion d’un utilisateur réel moyen sur le site Web, car ils peuvent disposer d’une connexion réseau plus rapide ou fonctionner sur un processeur plus lent. Ce que Lighthouse propose ressemble plus à tests « à la demande » c’est immédiatement disponible.

Cela rend les données simulées idéales pour exécuter des tests rapidement et dans certaines conditions artificiellement adoucies. Cependant, il sacrifie la précision en faisant des hypothèses sur les vitesses de connexion des visiteurs du site et en faisant la moyenne des choses d’une manière qui les sépare de la réalité.

Bien que la limitation simulée soit la valeur par défaut dans Lighthouse, elle prend également en charge méthodes de limitation plus réalistes. L’exécution de ces tests prendra plus de temps mais vous donnera des données plus précises. Le moyen le plus simple d’exécuter Lighthouse avec des paramètres plus réalistes consiste à utiliser un outil en ligne tel que Test de vitesse du site Web DebugBear ou Test de page Web.

Cela n’a pas d’impact sur les scores Core Web Vitals

Ces Éléments essentiels du Web dont tout le monde parle sont les mesures standard de Google pour mesurer les performances. Ils vont au-delà des simples rapports « Votre page chargée en X secondes » en examinant une multitude de détails plus pertinents qui diagnostiquent la façon dont la page se charge, les ressources qui pourraient bloquer d’autres ressources, les interactions lentes des utilisateurs et l’ampleur des déplacements de la page. du chargement des ressources et du contenu. Zeunert a un autre excellent article ici sur Smashing Magazine qui traite de chaque métrique en détail.

Le point principal ici est que les données simulées produites par Lighthouse peuvent (et c’est souvent le cas) différer des mesures de performances d’autres outils. J’ai passé beaucoup de temps à expliquer cela dans un autre article. L’essentiel est que Les scores Lighthouse n’ont pas d’impact sur les données Core Web Vitals. La raison en est que Core Web Vitals s’appuie sur des données sur les utilisateurs réels extraites de la mise à jour mensuelle. Rapport sur l’expérience utilisateur Chrome (CrUX). Bien que les données CrUX puissent être limitées par la date à laquelle elles ont été extraites récemment, elles reflètent plus précisément les comportements des utilisateurs et les conditions de navigation que les données simulées dans Lighthouse.

Le point ultime auquel je veux en venir est que Lighthouse est tout simplement inefficace pour mesurer les indicateurs de performances Core Web Vitals. Voici comment je l’explique dans mon article sur mesure :

« [Synthetic] les données sont fondamentalement limitées par le fait que il ne s’intéresse qu’à une seule expérience dans un environnement prédéfini. Souvent, cet environnement ne correspond même pas à l’utilisateur réel moyen sur le site Web, qui peut disposer d’une connexion réseau plus rapide ou d’un processeur plus lent.

J’ai souligné la partie importante. Dans la vraie vie, les utilisateurs sont susceptibles de vivre plusieurs expériences sur une page particulière. Ce n’est pas comme si vous naviguiez vers un site, le laissiez se charger, restiez là, puis fermiez la page ; vous êtes plus susceptible de faire quelque chose sur cette page. Et pour une métrique Core Web Vital qui recherche une peinture lente en réponse aux entrées de l’utilisateur, à savoir : Interaction avec la peinture suivante (INP) – il n’y a aucun moyen pour Lighthouse de mesurer cela !

C’est la même chose pour une métrique comme Cumulative Layout Shift (CLS) qui mesure le « stabilité visible » d’une mise en page car les changements de mise en page se produisent souvent plus bas sur la page après un utilisateur a fait défiler vers le bas. Si Lighthouse s’appuyait sur les données CrUX (ce qui n’est pas le cas), il serait alors capable de faire des hypothèses basées sur des utilisateurs réels qui interagissent avec la page et peuvent expérimenter CLS. Au lieu de cela, Lighthouse attend patiemment le chargement complet de la page et n’interagit jamais avec certaines parties de la page, n’ayant ainsi aucun moyen de savoir quoi que ce soit sur CLS.

Mais c’est quand même un « bon début »

C’est avec ça que je veux que tu repartes à la fin de la journée. Un rapport Lighthouse est incroyablement efficace pour produire des rapports rapidement, grâce aux données simulées qu’il utilise. En ce sens, je dirais que Lighthouse est un « contrôle instinctif » pratique et peut-être même une première étape pour identifier les opportunités d’optimisation des performances.

Mais ce n’est pas une image complète. Pour cela, nous souhaiterions un outil qui s’appuie sur données utilisateur réelles. Les outils qui intègrent les données CrUX y sont plutôt bons. Mais encore une fois, ces données sont extraites chaque mois (28 jours pour être exact), il se peut donc qu’il ne reflète pas les comportements et interactions les plus récents des utilisateurs, bien qu’il soit mis à jour quotidiennement sur une base continue et qu’il soit en effet possible de interroger les enregistrements historiques pour des échantillons de plus grande taille.

Mieux encore, utilisez un outil qui surveille les utilisateurs en temps réel.

Les données extraites directement du site d’origine sont véritablement les données de référence que nous souhaitons car elles proviennent de la source de vérité. Cela fait des outils qui s’intègrent à votre site le meilleur moyen d’obtenir des informations et de diagnostiquer les problèmes, car ils vous indiquent exactement comment vos visiteurs vivent votre site.

J’ai écrit sur en utilisant l’API Performance en JavaScript pour évaluer les métriques personnalisées et Core Web Vitals, il est donc possible de les déployer vous-même. Mais il existe de nombreux services existants qui font cela pour vous, avec des visualisations, des enregistrements historiques et des données réelles. surveillance des utilisateurs en temps réel (souvent abrégé en RHUM). Quelles prestations ? Bien, DebugBear est un excellent point de départ. J’ai cité Matt Zeunert plus tôt, et DebugBear est son produit.

Donc, si vous voulez une image complète des performances de votre site, allez-y et commencez par Lighthouse. Mais ne vous arrêtez pas là, car vous ne voyez qu’une partie du tableau. Vous voudrez augmenter vos découvertes et diagnostiquer les performances avec la surveillance des utilisateurs réels pour l’image la plus complète et la plus précise.

(gg, ouais)