Lighthouse : mesurer la vitesse d’un site et trouver des améliorations

Lighthouse est un outil d’audit automatisé qui identifie les problèmes et les améliorations possibles dans la performance, l’accessibilité, les meilleures pratiques et l’optimisation pour les moteurs de recherche (SEO) d’une page web. Analysez le chargement d’une page dans Chrome DevTools, tracez une métrique lente jusqu’aux requêtes, fichiers ou tâches d’exécution impliqués, modifiez une chose, puis mesurez à nouveau dans les mêmes conditions. Un score unique ne représente pas l’expérience de chaque visiteur ni ne détermine le classement d’une page dans les résultats de recherche.

Lighthouse et PageSpeed Insights : quelle est la différence ?

La présentation officielle de Lighthouse décrit les audits via Chrome DevTools, la ligne de commande ou un module Node. Les débutants peuvent commencer avec le panneau inclus dans Chrome pour ordinateur, sans installer d’extension. Cette méthode est également utile pour une page accessible après connexion ou une page de développement locale.

La documentation PageSpeed Insights distingue les données de laboratoire des données sur le terrain. Les données de laboratoire sont un diagnostic Lighthouse généré dans des conditions spécifiques. Les données sur l'expérience réelle des utilisateurs proviennent du Chrome User Experience Report (CrUX), couvrant la période de collecte des 28 jours précédents. Si une page possède trop peu d'échantillons, le service peut afficher les données pour l'origine (le même schéma d'URL, hôte et port) ou aucune donnée sur les utilisateurs réels. Disposer d'un résultat de laboratoire ne signifie pas que des statistiques des visiteurs réels sont disponibles pour cette page particulière.

Pour un contrôle rapide d'une URL publique, saisissez-la dans PageSpeed Insights, analysez-la, et sélectionnez séparément les résultats pour mobile et pour ordinateur. Pour les pages visibles uniquement après connexion, ou les URL locales qui ne peuvent pas être atteintes depuis l'extérieur, utilisez les DevTools locaux au lieu du service externe. Ne soumettez pas d'URL privées ni de jetons d'accès à un service d'analyse externe.

Les mesures d'un rapport décrivent l'URL cible et les conditions d'exécution. Une démonstration utilisant une URL publique d'exemple ne mesure pas le site web publiant le guide ni votre propre site web. Gardez la section sur l'expérience réelle de l'utilisateur séparée de la section diagnostique Lighthouse lors de la lecture d'un rapport.

Choisissez d'abord la page et les conditions de mesure

• Cible : spécifiez l'URL à tester, en incluant des articles représentatifs, des listes ou des pages produit plutôt que seulement la page d'accueil. Ne combinez pas différents modèles comme s'il s'agissait de résultats avant et après pour la même page.
• État : enregistrez s'il s'agit d'une première visite ou d'une visite répétée, l'état de connexion et la manière dont les bannières de consentement sont gérées. Pour une page publique qui ne nécessite pas de connexion, un profil séparé ou une fenêtre en mode incognito peut aider à réduire les effets des extensions.
• Environnement : enregistrez les versions de Chrome et Lighthouse, la sélection mobile ou bureau, la méthode de limitation du réseau et du processeur, et le moment de la mesure. Évitez d'exécuter de gros téléchargements ou d'autres tâches lourdes en même temps.
• Stockage : Le nettoyage du stockage supprime le stockage du site pour approximativement simuler une visite initiale. Cela peut affecter l'état de connexion et de consentement, donc ne l'activez pas à la légère dans une session contenant du travail important. Lors de l'audit d'une page connectée, choisissez des paramètres qui préservent l'état nécessaire et utilisez-les de manière cohérente pour les comparaisons ultérieures.

Auditer tout en étant connecté en tant qu'administrateur peut charger des scripts, barres d'outils et politiques de cache différents de ceux utilisés par un visiteur anonyme. Mesurez la page publique séparément lorsque la question concerne les lecteurs ordinaires. Si l'objectif est une fonctionnalité pour les utilisateurs connectés, enregistrez explicitement cet état.

Analysez le chargement d'une page dans Chrome DevTools

1. Ouvrez la page dans Chrome sur ordinateur. Vérifiez que l'adresse publique est correcte, par exemple, et que la page n'a pas été redirigée vers un écran d'erreur.
2. Ouvrez les DevTools, par exemple avec F12 ou Ctrl+Maj+I sous Windows. Si l'onglet Lighthouse est masqué, trouvez-le via le menu de débordement des onglets ou Plus d'outils dans le menu DevTools. Les noms des menus peuvent varier selon la langue et la version du navigateur.
3. Pour un audit de chargement initial de page, sélectionnez Navigation sous Mode. Choisissez Mobile ou Bureau sous Appareil. Le mode Mobile est un test en laboratoire avec des contraintes sélectionnées, plutôt qu'une reproduction de la performance de chaque téléphone réel.
4. Sélectionnez Performance sous Catégories, en ajoutant Accessibilité, Bonnes Pratiques ou SEO lorsque nécessaire. Vérifiez les paramètres de vidage de stockage et de limitation et conservez leurs valeurs identiques lors des comparaisons.
5. Sélectionnez Analyser le chargement de la page, ou le bouton de démarrage équivalent dans votre version. La page se recharge, donc enregistrez les formulaires non terminés ou tout autre travail non enregistré au préalable. Évitez d'interagir avec la page pendant l'analyse et attendez le rapport.
6. Vérifiez l'URL demandée, l'URL finale, les paramètres et les versions. Enregistrez le rapport en HTML ou JSON, en sélectionnant le format nécessaire si le menu d'exportation propose ce choix. Les rapports peuvent contenir des adresses internes ou des informations de diagnostic, donc considérez leur contenu avant de les partager.

Choisissez un mode différent pour les scénarios autres qu’un audit de chargement de base. La documentation du flux utilisateur Lighthouse distingue Navigation pour une navigation unique, Timespan pour une période pouvant inclure des interactions, et Snapshot pour l’état actuel de la page. Ne comparez pas les résultats d’Timespan ou d’Snapshot comme s’il s’agissait du score de performance complet de Navigation. Considérez l’Snapshot lorsque la question concerne un état spécifique, comme l’accessibilité lorsque le menu est ouvert.

Lisez les métriques et les indices diagnostiques avant de consulter le score

L’explication du calcul du score de performance décrit une moyenne pondérée de valeurs transformées des métriques. Réduire le nombre d’avertissements de diagnostic n’augmente pas le score d’un montant équivalent. Les scores de 90 à 100 sont affichés comme bons, de 50 à 89 comme nécessitant une amélioration, et de 0 à 49 comme faibles. Ces plages interprètent le score d’une exécution ; elles ne définissent pas tous les délais acceptables pour les utilisateurs réels.

La documentation TBT définit une tâche longue comme une tâche dépassant 50 millisecondes, le temps excédentaire au-delà de 50 millisecondes étant compté comme temps de blocage. Le TBT n'est pas la même mesure que l'Interaction to Next Paint (INP), qui concerne la réactivité aux interactions de l'utilisateur. Vérifiez séparément les métriques Core Web Vitals des utilisateurs réels—LCP, INP et CLS—dans les données terrain.

Développez les Insights et diagnostics du rapport pour trouver les éléments et ressources affectés. Si l’élément LCP est une image dans la fenêtre d’affichage initiale, commencez par sa taille de transfert et le moment de la requête. Pour les grands décalages de mise en page, vérifiez si un espace est réservé pour les images et les publicités. Se contenter d’activer le chargement différé pour une image importante du premier écran ou de retarder tous les scripts de la même manière peut nuire à l’affichage ou à la fonctionnalité nécessaires, donc identifiez d’abord la cause et l’utilisation.

Pour une investigation plus approfondie, continuez avec les enregistrements et les Insights dans le panneau Performance, comme expliqué dans les instructions de Lighthouse et du panneau Performance de Chrome. Des scores élevés en Accessibilité ou SEO ne garantissent pas une conformité complète à l’accessibilité ni un classement élevé dans les moteurs de recherche. L’utilisation du clavier et la qualité réelle du contenu, parmi d’autres aspects échappant aux vérifications automatisées, doivent encore être examinées.

Changez une chose et mesurez à nouveau dans les mêmes conditions

1. Choisissez un problème ayant un impact utilisateur substantiel et une cause spécifique. Pour une image surdimensionnée dans la fenêtre initiale, par exemple, expérimentez d’abord avec une image adaptée à sa taille affichée.
2. Conservez les fichiers originaux, les paramètres et le rapport. Effectuez les modifications localement ou dans un environnement de test, et vérifiez que les caches fournissent les nouveaux fichiers après le déploiement. Ne masquez pas les fonctionnalités nécessaires et ne servez pas une page différente uniquement pour l'audit dans le but d'obtenir un meilleur score.
3. Répétez les mesures avec la même URL, état de connexion, mode de l'appareil et paramètres de limitation du réseau et du processeur. Comparez les métriques brutes ainsi que la plage et la médiane des séries de tests répétées plutôt qu'un seul meilleur score. Si vous choisissez cinq exécutions par condition, par exemple, utilisez ce nombre à la fois avant et après le changement.
4. Vérifiez que la métrique ciblée s'améliore et que la mise en page, les boutons, les formulaires et les interactions au clavier fonctionnent toujours. Si le changement n'aide pas ou casse une fonctionnalité, restaurez les fichiers et paramètres enregistrés et cherchez une autre cause.

Le guide sur la variabilité des mesures explique que les changements du réseau, de l’appareil, du serveur ou de la page peuvent modifier les scores sans modification du code. L’état des publicités et des bannières de consentement fait aussi partie des conditions de comparaison. Notez dans le rapport la date, l’URL, les versions des outils, les paramètres, les métriques et le changement effectué. Évaluez les métriques des utilisateurs réels après une durée de collecte suffisante et avec assez d’échantillons.

Lorsque l'analyse échoue ou que les résultats diffèrent substantiellement

Si une page ne se charge pas, que l'accès est bloqué ou que les redirections échouent, vérifiez l'URL finale et une réponse HTTP normale avant d'interpréter un score. Ne retirez pas l'authentification pour exposer une page privée à un test externe. Pour les mesures locales, vérifiez les paramètres de connexion et de suppression du stockage. Si des extensions peuvent être impliquées, répétez la même cible dans un environnement avec moins d'influence des extensions.

Une différence entre PageSpeed Insights et le score de votre PC n'est pas automatiquement un échec. Comparez d'abord les versions de Lighthouse, les chemins d'accès au serveur, les modes d’appareil et les limitations du réseau et du processeur, ainsi que l'état des cookies. N'essayez pas de faire correspondre les scores mobile et desktop ; comparez les changements avant et après dans chaque condition et considérez les métriques des véritables visiteurs.