Lighthouse: optimiser la vitesse du site Web

Présentation

Utilisez le panneau Lighthouse pour effectuer un audit complet de votre site Web. Le panneau Lighthouse génère un rapport qui vous donne des informations sur les éléments suivants de votre site Web:

• Performances
• Accessibilité
• Bonnes pratiques
• SEO

... et bien d'autres métriques.

Le tutoriel suivant vous aide à vous familiariser avec Lighthouse dans les outils pour les développeurs Chrome.

Pour en savoir plus sur les autres façons dont Lighthouse peut améliorer la qualité de votre site Web, consultez la documentation Lighthouse.

Objectif du tutoriel

Ce tutoriel vous explique comment utiliser les outils pour les développeurs Chrome pour trouver des moyens de charger vos sites Web plus rapidement.

Lisez la suite ou regardez la version vidéo de ce tutoriel:

Prérequis

Vous devez avoir une expérience de base en développement Web, semblable à celle enseignée dans ce cours d'introduction au développement Web.

Vous n'avez pas besoin de connaître les performances de chargement.

Introduction

Je m\'appelle Tony. Tony est très célèbre dans la société féline. Il a créé un site Web pour que ses fans puissent découvrir ses plats préférés. Ses fans adorent le site, mais Tony entend sans cesse des plaintes concernant sa lenteur de chargement. Tony vous a demandé de l'aider à accélérer le site.

Étape 1: Effectuez un audit du site

Lorsque vous souhaitez améliorer les performances de chargement d'un site, commencez toujours par un audit. L'audit a deux fonctions importantes:

• Il crée une valeur de référence à laquelle vous pourrez comparer les changements ultérieurs.
• Il vous fournit des conseils pratiques sur les modifications qui auront le plus d'impact.

Configurer

Pour commencer, vous devez configurer un nouvel environnement de travail pour le site Web de Tony afin de pouvoir le modifier plus tard:

1. Remixez le projet du site Web sur Glitch. Votre nouveau projet s'ouvre dans un onglet. Cet onglet sera appelé onglet de l'éditeur.

   

   Le nom du projet passe de tony à un nom généré de manière aléatoire. Vous disposez maintenant de votre propre copie modifiable du code. Vous allez ensuite modifier ce code.

2. En bas de l'onglet de l'éditeur, cliquez sur Preview (Aperçu) > Preview in a new window (Aperçu dans une nouvelle fenêtre). La démonstration s'ouvre dans un nouvel onglet. Cet onglet sera appelé onglet de démonstration. Le chargement du site peut prendre un certain temps.

   

3. Ouvrez DevTools à côté de la démonstration.

   

Établir une référence

La référence est un enregistrement des performances du site avant que vous n'ayez apporté des améliorations.

1. Ouvrez le panneau Lighthouse. Il est peut-être masqué derrière double_arrow Autres panneaux.

   

2. Faites correspondre les paramètres de configuration de votre rapport Lighthouse à ceux de la capture d'écran. Voici une explication des différentes options:

   • check_box Vider l'espace de stockage. Si vous cochez cette case, tout le stockage associé à la page est effacé avant chaque audit. Laissez ce paramètre activé si vous souhaitez examiner l'expérience des visiteurs qui consultent votre site pour la première fois. Désactivez ce paramètre lorsque vous souhaitez utiliser l'expérience de visite répétée.
   • check_box Activer l'échantillonnage JS. Cette option est désactivée par défaut. Lorsqu'il est activé, il ajoute des piles d'appels JavaScript détaillées à la trace des performances, mais peut ralentir la génération de rapports. La trace est disponible sous more_vert Menu "Outils" > Afficher la trace non limitée une fois le rapport Lighthouse généré.
   • Limitation simulée (par défaut) arrow_drop_down. Cette option simule les conditions de navigation typiques sur un appareil mobile. On parle de "simulation", car Lighthouse ne limite pas réellement la bande passante pendant le processus d'audit. Il s'agit plutôt d'extrapoler le temps de chargement de la page dans des conditions mobiles. En revanche, le paramètre Limitation des outils pour les développeurs (avancée) limite réellement votre processeur et votre réseau, ce qui a pour conséquence d'allonger le processus d'audit.
   • Mode > radio_button_checked Navigation (par défaut). Ce mode analyse un seul chargement de page, ce dont nous avons besoin dans ce tutoriel. Pour en savoir plus, consultez la section Les trois modes.
   • Appareil > radio_button_checked Mobile. L'option mobile modifie la chaîne user-agent et simule un viewport mobile. L'option pour ordinateur désactive pratiquement les modifications apportées pour les mobiles.
   • Catégories > check_box Performances. Si vous n'activez qu'une seule catégorie, Lighthouse ne génère un rapport qu'avec l'ensemble d'audits correspondant. Vous pouvez laisser les autres catégories activées si vous souhaitez voir les types de recommandations qu'elles fournissent. Désactiver les catégories non pertinentes accélère légèrement le processus d'audit.

3. Cliquez sur Analyser le chargement de la page. Au bout de 10 à 30 secondes, le panneau Lighthouse affiche un rapport sur les performances du site.

   

Gérer les erreurs de rapport

Si un message d'erreur s'affiche dans votre rapport Lighthouse, essayez d'exécuter l'onglet de démonstration dans une fenêtre de navigation privée sans ouvrir d'autres onglets. Vous êtes ainsi sûr d'exécuter Chrome à partir d'un état propre. Les extensions Chrome, en particulier, peuvent interférer avec le processus d'audit.

Comprendre votre rapport

Le nombre en haut de votre rapport correspond au score global des performances du site. Plus tard, lorsque vous apporterez des modifications au code, ce nombre devrait augmenter. Plus le score est élevé, meilleures sont les performances.

Métriques

Faites défiler la page jusqu'à la section Métriques, puis cliquez sur Développer la vue. Pour consulter la documentation d'une métrique, cliquez sur En savoir plus.

Cette section fournit des mesures quantitatives des performances du site. Chaque métrique fournit des insights sur un aspect différent des performances. Par exemple, First Contentful Paint vous indique quand le contenu est peint pour la première fois à l'écran, ce qui constitue une étape importante dans la perception du chargement de la page par l'utilisateur, tandis que Time To Interactive marque le point auquel la page semble suffisamment prête pour gérer les interactions utilisateur.

Captures d'écran

Vous trouverez ci-dessous une série de captures d'écran montrant à quoi ressemblait la page au moment de son chargement.

Opportunités

La section Opportunités fournit des conseils spécifiques pour améliorer les performances de chargement de cette page en particulier.

Cliquez sur une opportunité pour en savoir plus.

Cliquez sur En savoir plus pour consulter la documentation expliquant pourquoi une opportunité est importante et obtenir des recommandations spécifiques pour y remédier.

Diagnostic

La section Diagnostic fournit plus d'informations sur les facteurs qui contribuent au temps de chargement de la page.

Audits réussis

La section Audits réussis indique ce qui fonctionne correctement sur le site. Cliquez pour développer la section.

Étape 2: Test

La section Opportunités de votre rapport Lighthouse vous donne des conseils pour améliorer les performances de la page. Dans cette section, vous implémentez les modifications recommandées dans le codebase, en auditant le site après chaque modification pour mesurer son impact sur la vitesse du site.

Activer la compression de texte

Votre rapport indique que l'activation de la compression du texte est l'une des principales opportunités d'amélioration des performances de la page.

La compression de texte consiste à réduire, ou compresser, la taille d'un fichier texte avant de l'envoyer sur le réseau. C'est un peu comme si vous compressiez un dossier avant de l'envoyer par e-mail pour réduire sa taille.

Avant d'activer la compression, voici quelques façons de vérifier manuellement si les ressources textuelles sont compressées.

Ouvrez le panneau Network (Réseau), puis cochez settings Settings (Paramètres) > check_box Use large request rows (Utiliser des lignes de requêtes volumineuses).

Chaque cellule Taille affiche deux valeurs. La valeur supérieure correspond à la taille de la ressource téléchargée. La valeur inférieure correspond à la taille de la ressource non compressée. Si les deux valeurs sont identiques, la ressource n'est pas compressée lorsqu'elle est envoyée sur le réseau. Dans cet exemple, les valeurs supérieure et inférieure de bundle.js sont toutes deux 1.4 MB.

Vous pouvez également vérifier la compression en inspectant les en-têtes HTTP d'une ressource:

1. Cliquez sur bundle.js, puis ouvrez l'onglet Headers (En-têtes).

   

2. Recherchez un en-tête content-encoding dans la section Response Headers (En-têtes de réponse). Vous ne devriez pas en voir, ce qui signifie que bundle.js n'a pas été compressé. Lorsqu'une ressource est compressée, cet en-tête est généralement défini sur gzip, deflate ou br. Pour en savoir plus sur ces valeurs, consultez les directives.

Assez d'explications. Il est temps d'apporter des modifications. Activez la compression de texte en ajoutant quelques lignes de code:

1. Dans l'onglet de l'éditeur, ouvrez server.js et ajoutez les deux lignes suivantes (en surbrillance) :

   ...
   const fs = require('fs');
   const compression = require('compression');
   
   app.use(compression());
   app.use(express.static('build'));
   ...
   

2. Veillez à placer app.use(compression()) avant app.use(express.static('build')).

   

3. Attendez que Glitch déploie la nouvelle version du site. Un emoji souriant en bas à gauche indique que le déploiement a réussi.

Utilisez les workflows que vous avez appris précédemment pour vérifier manuellement que la compression fonctionne:

1. Revenez à l'onglet de démonstration et actualisez la page.

   La colonne Taille devrait maintenant afficher deux valeurs différentes pour les ressources textuelles telles que bundle.js. La valeur supérieure de 269 KB pour bundle.js correspond à la taille du fichier envoyé sur le réseau, et la valeur inférieure de 1.4 MB correspond à la taille du fichier non compressé.

   

2. La section En-têtes de réponse pour bundle.js doit désormais inclure un en-tête content-encoding: gzip.

   

Exécutez à nouveau le rapport Lighthouse sur la page pour mesurer l'impact de la compression du texte sur les performances de chargement de la page:

1. Ouvrez le panneau Lighthouse, puis cliquez sur Effectuer un audit dans la barre d'action en haut de l'écran.

   

2. Laissez les paramètres tels quels et cliquez sur Analyser le chargement de la page.

   

Excellent ! Vous semblez faire des progrès. Votre score de performances globales devrait avoir augmenté, ce qui signifie que le site est de plus en plus rapide.

Compression de texte dans le monde réel

La plupart des serveurs disposent de solutions simples comme celle-ci pour activer la compression. Il vous suffit de rechercher comment configurer le serveur que vous utilisez pour compresser le texte.

Redimensionner les images

Votre nouveau rapport indique qu'ajuster correctement la taille des images est une autre opportunité à saisir.

Redimensionner les images permet d'accélérer le temps de chargement en réduisant leur taille de fichier. Si votre utilisateur affiche vos images sur l'écran d'un appareil mobile de 500 pixels de large, il n'y a vraiment aucune raison d'envoyer une image de 1 500 pixels de large. Idéalement, envoyez une image de 500 pixels de largeur maximum.

1. Dans votre rapport, cliquez sur Dimensionner correctement les images pour voir quelles images doivent être redimensionnées. Il semble que les quatre images soient plus grandes que nécessaire.

   

2. Dans l'onglet de l'éditeur, ouvrez src/model.js.

3. Remplacez const dir = 'big' par const dir = 'small'. Ce répertoire contient des copies des mêmes images redimensionnées.

4. Réalisez un nouvel audit de la page pour voir l'impact de cette modification sur les performances de chargement.

   

Il semble que ce changement n'ait qu'un impact mineur sur le score de performances global. Toutefois, le score ne montre pas clairement la quantité de données réseau que vous économisez pour vos utilisateurs. La taille totale des anciennes photos était d'environ 6,1 Mo, alors qu'elle n'est plus que d'environ 633 ko. Vous pouvez le vérifier dans la barre d'état en bas du panneau Network (Réseau).

Redimensionner des images dans le monde réel

Pour une petite application, un redimensionnement ponctuel comme celui-ci peut suffire. Toutefois, pour une application volumineuse, cette approche n'est évidemment pas évolutive. Voici quelques stratégies pour gérer les images dans les applications volumineuses:

• Redimensionnez les images pendant le processus de compilation.
• Créez plusieurs tailles de chaque image lors du processus de compilation, puis utilisez srcset dans votre code. Au moment de l'exécution, le navigateur choisit la taille la plus adaptée à l'appareil sur lequel il s'exécute. Consultez la section Images de taille relative.
• Utilisez un CDN d'images qui vous permet de redimensionner dynamiquement une image lorsque vous la demandez.
• Au minimum, optimisez chaque image. Cela peut souvent générer d'énormes économies. L'optimisation consiste à exécuter une image via un programme spécial qui réduit la taille du fichier image. Pour en savoir plus, consultez Optimisation des images essentielle.

Éliminez les ressources bloquant le rendu

Votre dernier rapport indique que l'élimination des ressources bloquant le rendu est désormais la plus grande opportunité.

Une ressource bloquant l'affichage est un fichier JavaScript ou CSS externe que le navigateur doit télécharger, analyser et exécuter avant de pouvoir afficher la page. L'objectif est d'exécuter uniquement le code CSS et JavaScript de base nécessaire pour afficher correctement la page.

La première tâche consiste donc à trouver le code qui n'a pas besoin d'être exécuté au chargement de la page.

1. Cliquez sur Éliminer les ressources bloquant l'affichage pour afficher les ressources bloquantes : lodash.js et jquery.js.

   

2. En fonction de votre système d'exploitation, appuyez sur les touches suivantes pour ouvrir le menu Command:

   • Sur Mac : Commande+Maj+P
   • Sur Windows, Linux ou ChromeOS : Ctrl+Maj+P

3. Commencez à saisir Coverage, puis sélectionnez Afficher la couverture.

   

   L'onglet Couverture s'ouvre dans le volet.

   

4. Cliquez sur Actualiser Actualiser. L'onglet Couverture fournit un aperçu de la quantité de code exécuté dans bundle.js, jquery.js et lodash.js pendant le chargement de la page.

   

   Cette capture d'écran indique qu'environ 74% et 30% des fichiers jQuery et Lodash ne sont pas utilisés, respectivement.

5. Cliquez sur la ligne jquery.js. DevTools ouvre le fichier dans le panneau Sources. Une ligne de code a été exécutée si une barre verte s'affiche à côté. Une barre rouge à côté d'une ligne de code signifie qu'elle n'a pas été exécutée et qu'elle n'est certainement pas nécessaire au chargement de la page.

   

6. Faites défiler le code jQuery. Certaines des lignes qui sont "exécutées" ne sont en réalité que des commentaires. Exécuter ce code via un outil de minification qui supprime les commentaires est un autre moyen de réduire la taille de ce fichier.

En résumé, lorsque vous travaillez avec votre propre code, l'onglet Couverture peut vous aider à analyser votre code ligne par ligne et à n'expédier que le code nécessaire au chargement de la page.

Les fichiers jquery.js et lodash.js sont-ils vraiment nécessaires pour charger la page ? L'onglet Blocage des requêtes peut vous montrer ce qui se passe lorsque les ressources ne sont pas disponibles.

1. Cliquez sur l'onglet Network (Réseau), puis ouvrez à nouveau le menu Command (Commande).

2. Commencez à saisir blocking, puis sélectionnez Afficher le blocage des requêtes. L'onglet Blocage des requêtes s'ouvre.

   

3. Cliquez sur Ajouter un motif, saisissez /libs/* dans la zone de texte, puis appuyez sur Entrée pour confirmer.

   

4. Actualisez la page. Les requêtes jQuery et Lodash sont rouges, ce qui signifie qu'elles ont été bloquées. La page se charge toujours et est interactive. Il semble donc que ces ressources ne soient pas du tout nécessaires.

   

5. Cliquez sur Supprimer tous les schémas pour supprimer le schéma de blocage /libs/*.

En règle générale, l'onglet Blocage des requêtes est utile pour simuler le comportement de votre page lorsqu'une ressource donnée n'est pas disponible.

Supprimez maintenant les références à ces fichiers du code et réexaminez la page:

1. Dans l'onglet de l'éditeur, ouvrez template.html.

2. Supprimez les balises <script> correspondantes:

   <head>
       ...
       <meta name="viewport" content="width=device-width, initial-scale=1">
       <script src="/libs/lodash.js"></script>
       <script src="/libs/jquery.js"></script>
       <title>Tony's Favorite Foods</title>
   </head>
   

3. Attendez que le site soit recompilé et redéployé.

4. Réalisez un nouvel audit de la page depuis le panneau Lighthouse. Votre score global devrait à nouveau avoir augmenté.

   

Optimiser le chemin critique du rendu dans le monde réel

Le chemin de rendu critique fait référence au code dont vous avez besoin pour charger une page. En général, vous pouvez accélérer le chargement de la page en n'envoyant que le code critique pendant le chargement de la page, puis en chargeant de manière différée tout le reste.

• Il est peu probable que vous trouviez des scripts que vous puissiez supprimer directement, mais vous constaterez souvent que de nombreux scripts n'ont pas besoin d'être demandés lors du chargement de la page et peuvent être demandés de manière asynchrone. Consultez la section Utiliser async ou defer.
• Si vous utilisez un framework, vérifiez s'il dispose d'un mode de production. Ce mode peut utiliser une fonctionnalité telle que le tree shaking afin d'éliminer le code inutile qui bloque le rendu critique.

Réduisez le travail du thread principal

Votre dernier rapport indique des économies potentielles mineures dans la section Opportunités, mais si vous faites défiler la section Diagnostics, il semble que le plus gros goulot d'étranglement soit une activité de thread principal excessive.

C'est dans le thread principal que le navigateur effectue la majeure partie du travail nécessaire pour afficher une page, comme l'analyse et l'exécution du code HTML, CSS et JavaScript.

L'objectif est d'utiliser le panneau Performances pour analyser le travail effectué par le thread principal pendant le chargement de la page, et trouver des moyens de différer ou de supprimer le travail inutile.

1. Accédez à Performances > Paramètres de capture, puis définissez Réseau sur 3G lente et CPU sur 6 fois plus lent.

   

   Les appareils mobiles présentent généralement plus de contraintes matérielles que les ordinateurs portables ou de bureau. Ces paramètres vous permettent donc de charger la page comme si vous utilisiez un appareil moins puissant.

2. Cliquez sur Actualiser Actualiser. Les outils de développement actualisent la page, puis génèrent une visualisation de tout ce qu'ils ont dû faire pour la charger. Cette visualisation sera appelée trace.

   

La trace affiche l'activité de manière chronologique, de gauche à droite. Les graphiques FPS, CPU et NET en haut de l'écran vous donnent un aperçu des images par seconde, de l'activité du processeur et de l'activité réseau.

Le mur jaune que vous voyez dans la section Vue d'ensemble signifie que le processeur était entièrement occupé par l'activité de script. Cela peut vous indiquer que vous pouvez accélérer le chargement de la page en effectuant moins de travail JavaScript.

Examinez la trace pour trouver des moyens de réduire le travail JavaScript:

1. Cliquez sur la section Durée pour la développer.

   

   Il existe de nombreuses mesures User Timing de React. Il semble que l'application de Tony utilise le mode développement de React. Passer au mode de production de React vous permettra probablement d'améliorer facilement les performances.

2. Cliquez à nouveau sur Durées pour réduire cette section.

3. Parcourez la section Principale. Cette section affiche un journal chronologique de l'activité du thread principal, de gauche à droite. L'axe Y (de haut en bas) indique pourquoi les événements se sont produits.

   

   Dans cet exemple, l'événement Evaluate Script a entraîné l'exécution de la fonction (anonymous), qui a entraîné l'exécution de __webpack__require__, qui a entraîné l'exécution de ./src/index.jsx, etc.

4. Faites défiler la page jusqu'en bas de la section Principale. Lorsque vous utilisez un framework, la plupart des activités supérieures sont causées par le framework, qui n'est généralement pas sous votre contrôle. L'activité générée par votre application se trouve généralement en bas.

   

   Dans cette application, il semble qu'une fonction appelée App génère de nombreux appels à une fonction mineBitcoin. Il semble que Tony utilise les appareils de ses fans pour miner des cryptomonnaies.

5. Ouvrez l'onglet Bottom-Up (De bas en haut) en bas de l'écran. Cet onglet détaille les activités qui ont pris le plus de temps. Si rien ne s'affiche dans la section De bas en haut, cliquez sur le libellé de la section Principale.

   

   La section De bas en haut n'affiche que les informations sur l'activité ou le groupe d'activités que vous avez actuellement sélectionnés. Par exemple, si vous avez cliqué sur l'une des activités mineBitcoin, la section De bas en haut n'affichera que les informations de cette activité.

   La colonne Temps propre indique le temps passé directement dans chaque activité. Dans ce cas, environ 82% du temps du thread principal a été consacré à la fonction mineBitcoin.

Il est temps de voir si l'utilisation du mode production et la réduction de l'activité JavaScript accélèrent le chargement de la page. Commencez par le mode de production:

1. Dans l'onglet de l'éditeur, ouvrez webpack.config.js.
2. Remplacez "mode":"development" par "mode":"production".
3. Attendez que le nouveau build soit déployé.

4. Réexaminez la page.

   

Réduisez l'activité JavaScript en supprimant l'appel à mineBitcoin:

1. Dans l'onglet de l'éditeur, ouvrez src/App.jsx.
2. Mettez en commentaire l'appel de this.mineBitcoin(1500) dans constructor.
3. Attendez que le nouveau build soit déployé.
4. Réexaminez la page.

Comme toujours, il reste des choses à faire, par exemple réduire les métriques Largest Contentful Paint (Plus grande peinture de contenu) et Cumulative Layout Shift (Décalage de mise en page cumulé).

Réduire le travail du thread principal dans le monde réel

En général, le panneau Performances est le moyen le plus courant de comprendre l'activité de votre site lors de son chargement et de trouver des moyens de supprimer les activités inutiles.

Si vous préférez une approche plus proche de console.log(), l'API User Timing vous permet de marquer de manière arbitraire certaines phases du cycle de vie de votre application afin de suivre la durée de chacune de ces phases.

Résumé

• Lorsque vous souhaitez optimiser les performances de chargement d'un site, commencez toujours par un audit. L'audit établit une référence et vous donne des conseils pour vous améliorer.
• Apportez une modification à la fois et effectuez un audit de la page après chaque modification pour voir comment cette modification isolée affecte les performances.

Étapes suivantes

Effectuez des audits sur votre propre site. Si vous avez besoin d'aide pour interpréter votre rapport ou trouver des moyens d'améliorer vos performances de chargement, découvrez toutes les façons d'obtenir de l'aide de la communauté DevTools:

• Signalez les bugs liés à ce document dans le dépôt developer.chrome.com.
• Signalez les bugs dans les outils pour les développeurs sur Bugs Chromium.
• Discutez des fonctionnalités et des modifications sur la liste de diffusion. Veuillez ne pas utiliser la liste de diffusion pour poser des questions d'assistance. Utilisez plutôt Stack Overflow.
• Obtenez de l'aide générale sur l'utilisation des outils pour les développeurs sur Stack Overflow. Pour signaler un bug, utilisez toujours les bugs Chromium.
• Envoyez-nous un tweet à l'adresse @ChromeDevTools.