Ce que vous pouvez apprendre de l'onglet Réseau de Chrome

L’onglet Réseau de Chrome révèle pourquoi votre site web semble lent. Même si votre code est parfait, une seule image surdimensionnée ou un point de terminaison API lent peut détruire l’expérience utilisateur. Comprendre ce panneau vous transforme : vous passez de quelqu’un qui devine les problèmes de performance à quelqu’un qui les diagnostique avec précision.

Comprendre l’analyse en cascade du réseau

Le graphique en cascade dans le panneau Réseau des Chrome DevTools raconte l’histoire de chaque milliseconde du chargement de votre page. Chaque barre horizontale représente le parcours d’une requête, de son initiation à son achèvement. Les couleurs ne sont pas décoratives : elles encodent des informations de chronométrage critiques.

Les segments verts indiquent le temps d’attente (TTFB - Time to First Byte), montrant combien de temps votre serveur met à répondre. Le bleu représente le temps de téléchargement du contenu. Lorsque le vert domine, votre serveur est le goulot d’étranglement. Lorsque le bleu domine, vous avez affaire à des ressources volumineuses ou à des contraintes de bande passante.

Les navigateurs modernes effectuent plusieurs requêtes simultanément, créant des barres parallèles dans la cascade. Les connexions HTTP/2 amplifient cette parallélisation, permettant des dizaines de requêtes sur une seule connexion. Recherchez les motifs en escalier : ils révèlent des chaînes de dépendances où une ressource bloque une autre, indiquant souvent des opportunités de restructurer votre stratégie de chargement.

Distinguer les goulots d’étranglement TTFB vs temps de téléchargement

Le débogage des performances web commence par identifier si la lenteur provient du serveur ou du réseau. Cliquez sur n’importe quelle requête et examinez l’onglet Timing. Si “Waiting (TTFB)” dépasse 200 ms, examinez votre backend : les requêtes de base de données, la logique API ou la configuration du serveur nécessitent probablement une optimisation.

Des temps de téléchargement longs pointent vers des solutions différentes. Un bundle JavaScript de 5 Mo peut se charger instantanément sur votre connexion fibre mais ramper sur les réseaux mobiles. La colonne Size affiche à la fois la taille transférée (compressée) et la taille réelle (non compressée). Lorsque ces chiffres divergent significativement, vous utilisez avec succès la compression. Lorsqu’ils sont similaires, activer gzip ou Brotli pourrait améliorer considérablement les performances.

La surcharge de connexion apparaît dans la répartition du chronométrage sous forme de DNS Lookup, Initial Connection et négociation SSL. Les visiteurs pour la première fois subissent les trois ; les visiteurs récurrents les ignorent généralement grâce à la réutilisation de connexion. Plusieurs requêtes vers le même domaine devraient partager des connexions : si ce n’est pas le cas, vous gaspillez des allers-retours.

Utiliser la limitation du réseau pour des tests en conditions réelles

La connexion gigabit de votre machine de développement masque les problèmes de performance. La limitation du réseau dans Chrome simule des conditions réalistes. Sélectionnez “Slow 3G” ou “Fast 4G” dans le menu déroulant de limitation pour expérimenter votre site comme le font les utilisateurs mobiles.

La limitation révèle la concurrence des ressources. Lorsque la bande passante devient rare, la colonne Priority devient cruciale. Les navigateurs attribuent la priorité Highest aux ressources bloquant le rendu, High aux images visibles et Low au contenu en dessous du pli. Des priorités mal alignées, comme un pixel de suivi avec une priorité High, gaspillent la précieuse bande passante initiale.

Les profils de limitation personnalisés vous permettent de correspondre à des scénarios spécifiques. Configurez les vitesses de téléchargement/envoi et la latence pour simuler la qualité de connexion médiane de vos utilisateurs, pas leur meilleur scénario.

Déboguer les requêtes HTTP et les réponses API

Le panneau Réseau des Chrome DevTools excelle dans le débogage des requêtes HTTP. Les requêtes échouées apparaissent en rouge, attirant immédiatement l’attention. Cliquez sur l’une d’elles pour inspecter les en-têtes, révélant des erreurs CORS, des échecs d’authentification ou des requêtes mal formées.

L’onglet Response affiche la sortie réelle du serveur, inestimable lorsque les API renvoient des messages d’erreur dans les corps de réponse malgré des codes de statut 200. L’onglet Preview rend les réponses JSON dans des arborescences lisibles et repliables, rendant les réponses API complexes navigables.

Les initiateurs de requêtes révèlent la causalité. Survolez la colonne Initiator pour voir la pile d’appels complète. Cela retrace les problèmes jusqu’à leur source : cette erreur 404 pourrait provenir d’un script tiers, pas de votre code.

Filtrer et isoler des ressources spécifiques

L’entrée Filter accepte des requêtes sophistiquées. Tapez larger-than:100k pour trouver les ressources volumineuses. Utilisez -domain:votredomaine.com pour isoler les requêtes tierces. Les expressions régulières comme /\.(jpg|png|gif)/ regroupent les ressources connexes.

Le filtrage Fetch/XHR isole les appels API du chargement des ressources, essentiel lors du débogage de la logique applicative par rapport aux problèmes de performance. La fonction de recherche (Cmd+F) recherche dans tous les corps de réponse et en-têtes, parfait pour trouver où des données sensibles pourraient fuiter ou pour localiser des réponses API spécifiques.

Informations pratiques sur les performances

L’onglet Coverage (accessible via le menu DevTools) superpose les données réseau avec des statistiques d’utilisation du code. Ce bundle JavaScript de 2 Mo pourrait n’utiliser que 30 % de son code au chargement initial, un signal clair pour implémenter le fractionnement de code.

Les exports HAR (HTTP Archive) capturent des sessions réseau entières pour analyse dans des outils spécialisés comme WebPageTest ou pour partage avec les membres de l’équipe. Faites un clic droit sur n’importe quelle requête et “Copy as cURL” pour reproduire des requêtes exactes dans le terminal ou Postman.

Conclusion

L’onglet Réseau de Chrome transforme les problèmes de performance mystérieux en informations exploitables. Maîtrisez le graphique en cascade, comprenez les répartitions de chronométrage et utilisez la limitation pour voir votre site à travers les connexions de vos utilisateurs. Ces compétences séparent les développeurs qui espèrent que leurs sites sont rapides de ceux qui savent exactement pourquoi ils le sont ou ne le sont pas.

FAQ

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.