Trouver le script qui ralentit une page avec les DevTools

Quatre causes derrière le même symptôme

Imaginons une page produit dont le contenu apparaît en deux secondes. Pourtant, le bouton d’ajout au panier ne réagit qu’une seconde plus tard. Le marqueur de chargement ne suffit pas à expliquer ce délai : une page peut avoir reçu ses ressources principales tout en continuant à occuper intensément le processeur.

Il faut d’abord distinguer quatre phénomènes que le mot « lent » mélange facilement.

Ces causes peuvent se cumuler. Un bundle de grande taille peut être lent à transférer, coûteux à analyser, puis déclencher une initialisation elle-même trop longue. L’enquête ne consiste donc pas à choisir un panneau favori, mais à construire une chronologie : quand le fichier est-il arrivé, quand le CPU a-t-il travaillé et quel appel a consommé ce temps ?

Enregistrer le scénario qui ralentit

Ouvrez les DevTools sur la page à examiner, puis le panneau Performance. Pour étudier le chargement, utilisez Record and reload : Chrome recharge la page, enregistre son activité et arrête automatiquement la capture quelques secondes après la fin du chargement. Les intitulés peuvent légèrement varier selon la version ou la langue de Chrome, mais le bouton associe l’enregistrement à un rechargement.

Le scénario doit reproduire le problème observé. Si le gel survient juste après le premier clic plutôt qu’au chargement, lancez un enregistrement d’exécution avec Record, effectuez uniquement cette interaction, puis arrêtez. Une trace courte est plus facile à lire et évite de mélanger le clic problématique avec du défilement, des animations ou d’autres actions sans rapport.

Ne cherchez pas encore un nom de fichier. Repérez d’abord l’intervalle où la page semble prête mais ne répond pas. Les marqueurs de chargement et la vue d’ensemble donnent le contexte ; la piste Main dira ensuite ce que faisait réellement le thread principal pendant ce délai.

Lire la piste Main

Dépliez la piste Main. Elle prend la forme d’un graphique en flammes : le temps avance horizontalement, tandis que l’empilement vertical représente la chaîne d’appels. Une barre large dure longtemps ; une barre placée sous une autre a été provoquée par l’activité située au-dessus.

Chrome signale les tâches longues par un triangle rouge et teinte en rouge la partie située au-delà de 50 ms. Ce seuil n’affirme pas qu’un fichier entier est mauvais : il indique qu’une tâche a retenu le thread principal assez longtemps pour retarder une entrée utilisateur ou le rendu. Cliquez sur une de ces tâches, puis zoomez sur son intervalle. La zone de détails, souvent ouverte sur Summary, affiche notamment la durée totale, la durée propre, l’URL d’origine et, lorsqu’elles sont disponibles, la pile d’appels et la ligne du script.

La couleur jaune correspond généralement à l’activité de script, mais la couleur seule ne suffit pas. Une fonction JavaScript peut déclencher des recalculs de style, du layout ou du rendu, visibles dans d’autres couleurs. Dans ce cas, le coût apparent n’est pas seulement « exécuter du JavaScript » : la fonction provoque aussi un travail du moteur de rendu. La relation parent-enfant de la pile est plus instructive que la teinte isolée d’un bloc.

Pour notre page produit, supposons qu’une tâche de 780 ms commence après l’affichage du contenu. À l’intérieur, un événement Evaluate Script mène à plusieurs appels de fonctions et à des recalculs de style. Le fichier était donc disponible au moment du gel ; la piste suggère désormais un coût CPU, qu’il reste à attribuer précisément.

Remonter à la fonction et au fichier

Sélectionnez seulement la portion de trace qui couvre la tâche longue. Ouvrez ensuite Bottom-up. Cette vue agrège les activités sur l’intervalle choisi et place en tête celles qui ont consommé le plus de temps directement. Triez par Self Time pour faire ressortir une fonction coûteuse en elle-même ; Total Time inclut aussi le temps passé dans ses descendants.

Si hydrateCatalog apparaît avec une durée propre élevée, c’est un suspect solide. Si sa durée totale est élevée mais sa durée propre faible, développez sa pile : le vrai coût se trouve probablement dans une fonction appelée plus bas. La vue Call tree raconte la même période depuis les activités racines. Elle répond à une autre question : quel événement, minuteur ou script a lancé toute cette chaîne de travail ?

Le passage de l’une à l’autre évite deux erreurs. Bottom-up empêche d’accuser seulement le premier appel visible ; Call tree conserve le contexte qui explique pourquoi la fonction a été exécutée. Les liens associés aux appels ouvrent le fichier correspondant dans Sources. Le panneau Summary peut également proposer un lien vers la ligne source de l’événement sélectionné.

Quand la production ne montre que des noms illisibles

En production, le navigateur exécute souvent un bundle regroupé et minifié. Sans carte de sources, la trace peut ne montrer que a, n, une fonction anonyme ou une position dans app.8f3c.js. Le formatage automatique rend ce fichier plus lisible, mais ne reconstitue ni les noms d’origine ni l’organisation du projet.

Les source maps relient le code déployé aux fichiers écrits par l’équipe. Lorsqu’elles sont disponibles et que l’option JavaScript source maps est activée dans les réglages de Sources, DevTools peut afficher la fonction et le fichier d’origine, puis y ouvrir la bonne déclaration. Si elles sont absentes du site public, reproduisez le problème sur un environnement de test qui publie des cartes compatibles. Évitez d’exposer dans une carte publique du code ou des chemins que votre politique de déploiement considère comme sensibles.

Network départage le réseau du CPU

La trace révèle ce qui occupe le processeur, mais elle ne remplace pas le panneau Network. Rechargez la page avec l’enregistrement réseau actif, filtrez sur JS, puis examinez le fichier suspect. La waterfall le replace parmi les autres requêtes : une barre décalée vers la droite a démarré tard, tandis qu’une longue portion d’attente ou de téléchargement signale un problème avant l’exécution.

Ouvrez la vue Timing de la requête. Waiting (TTFB) couvre notamment la latence aller-retour et le temps de préparation de la réponse par le serveur. Content Download correspond à la réception du corps. Un TTFB dominant oriente donc vers l’attente réseau ou serveur ; un téléchargement dominant vers le débit ou le volume transféré. Si ces phases sont brèves mais qu’une longue tâche commence juste après, le goulet est plus probablement côté CPU.

La colonne Size indique la taille livrée avec les en-têtes. En activant les grandes lignes de requêtes, DevTools peut aussi montrer la taille de ressource non compressée. Cette différence compte : la compression réduit le transfert, pas la quantité de JavaScript que le moteur devra traiter après décompression. Comparez donc les octets à la durée, sans déduire le coût d’exécution de la seule taille du fichier.

Enfin, Initiator explique ce qui a demandé la ressource. Pour une requête lancée par JavaScript, la colonne peut mener à la ligne correspondante et son survol afficher la pile d’appels. Elle aide à découvrir qu’un petit chargeur injecte un second bundle ou qu’un gestionnaire de consentement déclenche plusieurs balises. Elle ne prouve toutefois pas que l’initiateur consomme lui-même le CPU : elle décrit une dépendance réseau, à confronter à la trace Performance.

Mettre un script tiers à l’épreuve

Analytics, publicité, lecteur vidéo, widget de discussion et gestionnaire de consentement sont des suspects fréquents, car ils peuvent télécharger d’autres ressources puis exécuter du code sur le thread principal. Le domaine affiché dans Network n’est pourtant pas un verdict. Un script tiers léger peut simplement déclencher une fonction coûteuse de votre application ; à l’inverse, un gestionnaire de balises servi depuis votre propre domaine peut charger plusieurs fournisseurs.

Dans la trace, la table 1st / 3rd party du résumé peut rapprocher tailles transférées et temps de thread principal par entité. L’option Dim 3rd parties atténue les événements tiers pour faire ressortir le code du site. Ces vues donnent une direction, puis Bottom-up, la pile d’appels et les URL de fichiers doivent confirmer l’attribution.

Changer une seule variable

La confirmation la plus simple est une comparaison contrôlée. Dans un environnement local ou de test, enregistrez une trace de référence. Désactivez temporairement uniquement le script suspect dans la configuration de cet environnement, rechargez dans les mêmes conditions et enregistrez une seconde trace. Comparez le même intervalle : la tâche longue a-t-elle disparu, sa durée a-t-elle réellement baissé et la page reste-t-elle fonctionnelle ?

Sans modifier l’application, DevTools permet aussi de faire un essai local. Dans Network, un clic droit sur la requête propose de la bloquer ; le tiroir Request conditions s’ouvre alors avec la règle active. Rechargez et reprenez une trace, puis désactivez ou supprimez la règle après le test. Vérifiez le statut (blocked:devtools) pour ne pas confondre cette simulation avec une panne réelle.

Répétez la mesure plusieurs fois si le résultat est serré, car le cache, le réseau et le comportement dynamique d’un fournisseur introduisent du bruit. Surtout, ne bloquez qu’un élément à la fois. Si trois scripts disparaissent entre les deux traces, l’amélioration est réelle mais son responsable reste inconnu.

Ce que Coverage et Lighthouse ajoutent

Coverage devient utile lorsqu’un fichier paraît lourd mais exécute peu de code pendant le scénario enregistré. Le panneau rapporte les octets JavaScript utilisés et inutilisés, puis ouvre la ressource dans Sources avec une lecture ligne par ligne. Il distingue ainsi le poids envoyé du code effectivement sollicité lors de cette visite.

Cette mesure reste liée au parcours capturé. Une fonction marquée inutilisée au chargement peut devenir indispensable après l’ouverture d’un menu, une authentification ou une autre route. Coverage soutient une décision de découpage ou de chargement différé ; il ne suffit pas, à lui seul, pour supprimer du code.

Lighthouse joue un rôle voisin mais plus général. Son rapport signale des pistes et des métriques de laboratoire, notamment le temps de blocage. Il est excellent pour savoir qu’une page mérite une enquête. Pour attribuer le temps à une tâche, une fonction ou un script précis, la trace Performance reste l’outil central. La documentation actuelle de Chrome recommande d’ailleurs ce panneau pour un débogage plus détaillé.

Conclure sur des preuves

Sur notre page produit, la cascade montre que le bundle arrive rapidement. La longue tâche commence ensuite sur Main ; Bottom-up concentre le temps propre dans une fonction de classement, Call tree révèle qu’elle est déclenchée par l’initialisation des recommandations et les source maps ouvrent le fichier TypeScript d’origine. Une seconde trace, réalisée avec ce module désactivé dans l’environnement de test, fait disparaître le gel. L’enquête a isolé une cause CPU et non un téléchargement lent.

La méthode tient en une chaîne de preuves : reproduire le symptôme, situer le temps perdu, identifier la tâche, suivre sa pile jusqu’au code, vérifier le réseau, puis modifier une seule variable. C’est ce qui transforme « la page est lente à cause du JavaScript » en diagnostic que l’équipe peut réellement corriger.