PageSpeed Insights et Lighthouse vous disent si une page est lente et suggèrent où agir. Mais quand il faut comprendre pourquoi un LCP arrive tard, quel script bloque un clic ou quel élément provoque un décalage de mise en page, il faut un outil qui montre ce que fait le navigateur, milliseconde par milliseconde. Cet outil, c’est le panneau Performance des DevTools de Chrome, le même que celui qu’utilisent les développeurs des navigateurs et les spécialistes de la performance.
Au premier regard, il intimide : des dizaines de pistes colorées, des termes techniques, des milliers d’événements. En réalité, la plupart des diagnostics n’exigent que quelques fonctions, utilisées avec méthode. Dans ce guide, nous voyons comment préparer un enregistrement fiable, comment le lire et comment l’utiliser pour diagnostiquer les problèmes à l’origine des trois Core Web Vitals.
Avant d’enregistrer
Un enregistrement n’est utile que s’il reproduit des conditions réalistes. Trois précautions font la différence :
- une fenêtre propre : les extensions du navigateur exécutent du code sur chaque page et apparaissent dans l’enregistrement, ce qui brouille le diagnostic. Une fenêtre de navigation privée ou un profil invité, sans extensions, évite le problème ;
- la limitation du processeur : l’ordinateur d’un développeur est bien plus rapide que le smartphone moyen. Le panneau permet de ralentir le processeur de quatre ou six fois, et les versions récentes proposent des valeurs calibrées sur la machine utilisée pour simuler des appareils d’entrée et de milieu de gamme. Sans limitation, beaucoup de problèmes n’apparaissent tout simplement pas ;
- la limitation du réseau : pour les problèmes de chargement, comme le LCP, mieux vaut simuler une connexion mobile. Pour les problèmes d’interaction, comme l’INP, le réseau compte moins et peut rester sans limitation.
Quand vous ouvrez le panneau, avant même d’enregistrer, les versions récentes de Chrome affichent une vue de métriques en direct : LCP, CLS et INP mesurés sur la page pendant que vous l’utilisez, avec la possibilité de les comparer aux données d’utilisateurs réels du Chrome UX Report. C’est un bon point de départ : il vous dit tout de suite si le problème que vous poursuivez se reproduit sur votre ordinateur avec les réglages choisis, et si les conditions du test sont comparables à celles de vos utilisateurs.
Enregistrer un chargement de page
Pour analyser le chargement, on utilise le bouton qui recharge la page et enregistre : le navigateur efface l’enregistrement, recharge la page et s’arrête peu après la fin du chargement. Décidez au préalable si vous voulez étudier une première visite, avec un cache vide, ou une visite répétée : les résultats sont très différents, et la première visite est en général la plus critique. Vous pouvez désactiver le cache depuis le panneau Network pendant l’enregistrement.
Pour analyser une interaction, en revanche, on lance un enregistrement normal, on effectue l’action sur la page, comme ouvrir un menu ou appliquer un filtre, puis on arrête l’enregistrement. Les enregistrements courts sont plus faciles à lire : quelques secondes, centrées sur l’action qui vous intéresse.
Lire l’enregistrement
L’enregistrement apparaît sous la forme d’une série de pistes horizontales alignées sur le même axe temporel. Les plus importantes sont au nombre de cinq.
La vue d’ensemble (overview), en haut, montre l’activité du processeur au fil du temps, avec les couleurs des différentes activités, et une pellicule de captures d’écran de la page. Elle aide à s’orienter : on voit immédiatement les moments où le navigateur est occupé et l’on peut sélectionner une plage pour zoomer dessus.
Les pistes réseau et timings montrent les requêtes dans le temps, comme un waterfall compact, et les moments clés du chargement, dont le FCP et le LCP. Si vous sélectionnez le repère du LCP, le panneau indique quel élément a été considéré comme le plus grand.
La piste des interactions montre chaque clic, tap ou appui sur une touche enregistré, avec sa durée totale. Les interactions lentes sont mises en évidence.
Le thread principal est le cœur de l’enregistrement. Le travail y est représenté sous forme de flame chart : chaque rectangle est une activité, sa largeur est sa durée, et les rectangles en dessous sont les fonctions appelées par celui du dessus. Les couleurs indiquent le type de travail : jaune pour l’exécution des scripts, violet pour le calcul des styles et du layout, vert pour la peinture. Les tâches qui dépassent 50 millisecondes, les tâches longues (long tasks), sont marquées d’un triangle rouge et la partie en excès est mise en évidence.
Le panneau du bas montre le détail de ce qui est sélectionné. L’onglet Summary répartit le temps entre les catégories d’activités. L’onglet Bottom-Up liste les fonctions qui ont consommé le plus de temps, et permet de les regrouper par domaine ou par produit : c’est le moyen le plus rapide de voir combien pèsent les scripts tiers. Le Call Tree montre les mêmes informations en partant du haut, et l’Event Log liste les activités par ordre chronologique.
Les analyses automatiques
Les versions récentes du panneau placent à côté de l’enregistrement une colonne d’analyses (insights), issues en grande partie des audits Lighthouse mais reliées directement à la trace : la décomposition du LCP en phases, les ressources bloquant le rendu, la découverte de la requête de l’élément du LCP, les causes des décalages de mise en page, l’impact des tiers, la taille du DOM, les recalculs de layout forcés. Quand vous sélectionnez une analyse, le panneau met en évidence les événements correspondants dans l’enregistrement. Pour les débutants, c’est la meilleure porte d’entrée : on part d’un problème signalé et on voit où il se trouve.
Diagnostiquer le LCP
Pour le LCP, la question est : où est passé le temps entre la requête de la page et l’apparition du plus grand élément ? Le panneau le décompose en quatre phases. Le time to first byte dit combien de temps le serveur a mis. Le délai de chargement (load delay) est le temps entre le premier octet et le début du téléchargement de la ressource de l’élément du LCP, par exemple l’image principale : s’il est long, l’image a été découverte tard, parce qu’elle était chargée par un script, référencée seulement dans le CSS ou ralentie par le lazy loading. La durée de chargement (load duration) est le temps de téléchargement de la ressource : si elle est longue, la ressource est trop lourde ou la connexion est lente. Le délai de rendu (render delay) est le temps entre la fin du téléchargement et le moment où l’élément apparaît : s’il est long, le thread principal était occupé ou le rendu était bloqué par des feuilles de style et des scripts.
Savoir quelle phase domine indique tout de suite la direction : le serveur et le cache dans le premier cas, la priorité et la découverte de la ressource dans le deuxième, le poids de l’image dans le troisième, le CSS et le JavaScript dans le quatrième.
Diagnostiquer le CLS
Pour le CLS, le panneau propose une piste dédiée aux décalages de mise en page, regroupés dans les fenêtres utilisées pour calculer la métrique. Quand vous sélectionnez un décalage, le panneau indique quels éléments ont bougé et, quand il peut l’identifier, la cause probable : une image sans dimensions, une police web qui modifie les métriques du texte, un contenu inséré dynamiquement. Les captures d’écran de la vue d’ensemble, observées de part et d’autre du décalage, aident à comprendre ce qui s’est passé à l’écran.
Diagnostiquer l’INP
Pour l’INP, on enregistre l’interaction lente et on la sélectionne dans la piste des interactions. Le panneau la décompose en trois phases, chacune avec un remède différent.
Le délai d’entrée (input delay) est le temps que l’interaction a attendu que le thread principal se libère. S’il est long, il suffit de regarder ce que faisait le thread principal au moment du clic : souvent, c’est un script tiers, un minuteur ou la fin du chargement. Le traitement (processing) est l’exécution des gestionnaires d’événements : le flame chart montre quelles fonctions ont pris le plus de temps, et si le code alterne lectures et modifications de la mise en page, le panneau signale les recalculs forcés. La présentation (presentation) est le travail nécessaire pour afficher le résultat : calcul des styles, layout, peinture. Si elle est longue, la page a en général un DOM très volumineux ou la modification concerne de nombreux éléments, comme on l’a vu dans les articles sur le coût du DOM et sur le CSS moderne.
Les outils qui l’accompagnent
Le panneau Performance ne travaille pas seul. Le panneau Network permet d’examiner en détail chaque requête, avec les en-têtes, les priorités et les temps de connexion. Le panneau Rendering, accessible depuis le menu des DevTools, met en évidence à l’écran les zones repeintes et les décalages de mise en page pendant que vous utilisez la page, et sert à repérer d’un coup d’œil les animations coûteuses. Le panneau Coverage montre quelle part du CSS et du JavaScript téléchargés est réellement utilisée. Lighthouse, intégré aux mêmes DevTools, offre la vue d’ensemble avec ses audits, tandis que le panneau Performance permet de vérifier en détail ce que les audits signalent : comme l’explique l’article sur les différences entre PageSpeed Insights et Lighthouse, ce sont des outils complémentaires, pas alternatifs.
Les erreurs les plus courantes
- enregistrer sans limitation : sur un ordinateur rapide, tout semble rapide, et l’on conclut que le problème n’existe pas ;
- se fier à un seul enregistrement : les durées varient d’une exécution à l’autre. Pour comparer un avant et un après, il faut plusieurs enregistrements, en regardant la tendance et non la valeur isolée ;
- confondre laboratoire et terrain : l’enregistrement montre ce qui se passe sur votre propre ordinateur, dans des conditions simulées. Comme l’explique le texte sur CrUX et les données de laboratoire, c’est un outil de diagnostic : le verdict final revient aux données d’utilisateurs réels ;
- se perdre dans les détails : un enregistrement contient des milliers d’événements, et les étudier tous n’a aucun sens. Mieux vaut partir de la métrique à améliorer, trouver le moment correspondant et remonter à la cause ;
- oublier les extensions : un bloqueur de publicités ou un gestionnaire de mots de passe peut ajouter un travail que vos utilisateurs n’ont pas, ou retirer des scripts que vos utilisateurs exécutent.
Enregistrer et partager
Un enregistrement peut être sauvegardé dans un fichier et rouvert plus tard, même sur un autre ordinateur. C’est utile pour documenter l’état d’une page avant une modification, le comparer à l’état d’après et partager un diagnostic avec un développeur ou un prestataire. Les versions récentes permettent aussi d’ajouter des annotations directement sur l’enregistrement, en mettant en évidence une plage ou en reliant deux événements, pour que le destinataire sache tout de suite où regarder. Gardez à l’esprit qu’un enregistrement peut contenir des URL, des paramètres et des captures d’écran de la page : si la page affiche des données confidentielles, partagez-le avec précaution.
Un exemple concret
Un site de petites annonces reçoit, dans le rapport de la Search Console, un avertissement d’INP médiocre sur ses pages de recherche. En laboratoire, sans limitation, les filtres semblent répondre instantanément. Avec le processeur ralenti de quatre fois et un enregistrement fait pendant l’application d’un filtre, l’interaction dure presque 400 millisecondes. La décomposition montre un délai d’entrée important, causé par un script de chat qui exécute une tâche longue toutes les quelques secondes, et une longue phase de traitement, pendant laquelle le gestionnaire de clic reconstruit toute la liste des résultats. L’onglet qui regroupe par produit confirme que le script de chat occupe une part importante du thread principal. Les corrections sont claires : ne charger le chat que lorsque l’utilisateur l’ouvre, et ne mettre à jour que les éléments de la liste qui changent. Une deuxième série d’enregistrements confirme l’amélioration, et dans les semaines suivantes les données d’utilisateurs réels la vérifient.
En bref
Le panneau Performance montre ce que fait le navigateur pendant le chargement et les interactions, et c’est l’outil qui transforme un score en diagnostic. Pour bien l’utiliser, il faut des conditions réalistes, c’est-à-dire une fenêtre sans extensions et un processeur bridé, et une méthode : partir de la métrique à améliorer, trouver le moment correspondant dans l’enregistrement, le décomposer en phases et remonter à la cause dans le thread principal. Les analyses automatiques et la vue de métriques en direct facilitent la prise en main. Le reste est affaire de pratique : après quelques enregistrements, les pistes colorées deviennent une carte lisible de l’endroit où part le temps.
