De tous les outils d’analyse de la performance, le diagramme en cascade des requêtes réseau, le fameux waterfall, est probablement le plus riche en informations et le moins lu. Les scores et les métriques vous disent si une page est lente ; le waterfall vous dit pourquoi. Il montre chaque ressource téléchargée, le moment où le navigateur l’a découverte, combien de temps elle a attendu, combien de temps le serveur a mis à répondre, combien a duré le téléchargement et dans quel ordre tout cela s’est passé. Celui qui apprend à le lire trouve, en quelques minutes, des problèmes qu’aucun rapport automatique ne décrit avec la même clarté.
Dans cet article, nous voyons où trouver le waterfall, comment en lire chaque partie, quels motifs récurrents signalent un problème et comment s’en servir pour vérifier qu’une modification a vraiment fonctionné. Les exemples portent sur le panneau Réseau de Chrome DevTools et sur WebPageTest, les deux outils les plus répandus, mais les concepts valent pour n’importe quel outil qui montre les requêtes dans le temps.
Où le trouver
Dans le navigateur, le panneau Réseau de Chrome DevTools affiche la liste des requêtes avec une colonne Waterfall à droite. Il vaut mieux recharger la page avec le cache désactivé, grâce à la case prévue à cet effet, et avec une limitation du réseau et du processeur qui simule un appareil mobile : sur un ordinateur rapide avec une connexion fibre, de nombreux problèmes ne se voient tout simplement pas. Le panneau Performances offre une piste réseau alignée sur celle du thread principal, utile pour comprendre ce qui se passe dans le navigateur pendant que les ressources arrivent.
WebPageTest exécute le test sur de vrais appareils et de vraies connexions, depuis plusieurs lieux, et produit un waterfall très détaillé, avec les phases de chaque requête codées par couleur, les principaux événements repérés par des lignes verticales, l’utilisation du processeur et de la bande passante sous le graphique et une pellicule (filmstrip) qui montre la page au fur et à mesure de sa construction. C’est l’outil de référence pour l’analyse approfondie et pour comparer différentes versions d’une page. PageSpeed Insights aussi, dans sa section de diagnostic, affiche l’arbre des dépendances réseau, une vue qui met en évidence les chaînes de requêtes critiques.
L’anatomie du graphique
Chaque ligne du waterfall est une requête, et l’axe horizontal est le temps écoulé depuis le début de la navigation. L’endroit où la barre commence indique quand le navigateur a lancé la requête, c’est-à-dire quand il a découvert la ressource et décidé de la télécharger. La longueur indique combien de temps elle a duré. La couleur, selon l’outil, indique le type de ressource, la phase de la requête ou les deux.
À l’intérieur de chaque barre, on distingue les phases de la requête. Les trois premières n’apparaissent que lorsque le navigateur ouvre une nouvelle connexion vers un domaine : la résolution DNS, qui traduit le nom en adresse ; la connexion TCP ; la négociation TLS pour le chiffrement. Vient ensuite l’attente, le temps entre l’envoi de la requête et l’arrivée du premier octet de la réponse, qui correspond au travail du serveur et au temps d’aller-retour sur le réseau. Enfin le téléchargement proprement dit, dont la durée dépend de la taille de la ressource et de la bande passante disponible. Avant tout cela, il peut y avoir un temps de mise en file d’attente, quand le navigateur a découvert la ressource mais ne l’a pas encore demandée, par exemple parce qu’elle a une faible priorité ou parce qu’il y a trop de requêtes simultanées.
Les lignes verticales marquent les événements de la page : First Contentful Paint, quand le premier contenu apparaît ; Largest Contentful Paint ; l’événement DOMContentLoaded, quand le document a été analysé et que les scripts différés se sont exécutés ; l’événement load, quand toutes les ressources initiales ont été téléchargées. La position des requêtes par rapport à ces lignes en dit long : tout ce qui précède le premier affichage est, potentiellement, quelque chose que l’utilisateur attend devant un écran blanc.
Une méthode de lecture en huit questions
Face à un waterfall de dizaines ou de centaines de requêtes, il est facile de se perdre. Une méthode aide : toujours poser les mêmes questions, dans le même ordre.
1. Combien de temps dure la première requête ?
La première ligne est le document HTML, et tout le reste en dépend. Si sa phase d’attente dure une demi-seconde ou plus, le problème principal est le serveur : la page n’est pas servie depuis le cache, l’application est lente ou le serveur est éloigné. C’est le domaine du TTFB et du cache de page, et aucune optimisation côté front-end ne peut récupérer ce temps. Si une ou plusieurs redirections apparaissent avant le document, chacune ajoute un aller-retour complet de requête et de réponse : il faut les éliminer, par exemple en faisant pointer les liens directement vers l’adresse finale.
2. Qu’est-ce qui bloque le premier affichage ?
Les ressources qui bloquent le rendu, c’est-à-dire les feuilles de style dans le head et les scripts synchrones, doivent être téléchargées avant que le navigateur puisse afficher quoi que ce soit. WebPageTest les signale par une icône dédiée. Il vaut la peine de les compter et d’examiner leur durée : plus elles sont nombreuses et lourdes, plus le premier affichage arrive tard. Les solutions sont celles présentées dans les articles sur le CSS critique et sur le report des scripts.
3. Quand la ressource LCP démarre-t-elle ?
C’est la question la plus importante pour le LCP. Trouvez la ressource de l’élément LCP, généralement une image, et regardez quand sa barre commence par rapport au document. Idéalement, elle devrait démarrer juste après l’arrivée du HTML, en parallèle des feuilles de style. Si elle démarre beaucoup plus tard, après le CSS, après les scripts ou après d’autres images, il y a un problème de découverte ou de priorité : l’image est insérée par JavaScript, c’est un arrière-plan défini dans le CSS, elle est en lazy loading ou elle a une faible priorité. Les solutions se trouvent dans l’article sur preload, preconnect et fetchpriority.
4. Y a-t-il des chaînes ?
Une chaîne de requêtes se reconnaît à sa forme d’escalier : une ressource qui ne démarre que lorsque la précédente est terminée, parce que c’est la précédente qui la demande. La feuille de style qui en importe une autre, laquelle déclare une police ; le script qui en charge un autre, qui charge une image. Chaque marche ajoute un aller-retour réseau complet. Il faut raccourcir les chaînes, en déplaçant les ressources finales plus haut dans le document ou en les avançant avec un preload.
5. Combien de domaines et combien de connexions ?
Chaque domaine différent exige une nouvelle connexion, visible dans le waterfall sous la forme de la séquence colorée DNS, TCP et TLS au début de la barre. Sur un réseau mobile, chaque ouverture peut coûter de 100 à 300 millisecondes. Si le waterfall montre beaucoup de ces séquences, surtout avant le premier affichage, il faut se demander quels domaines sont réellement nécessaires : polices provenant de services externes, bibliothèques provenant de CDN publics, scripts tiers. Héberger les ressources critiques sur votre propre domaine élimine ces ouvertures ; pour les domaines indispensables, un preconnect les avance.
6. Y a-t-il des trous ?
Parfois, le waterfall montre des intervalles pendant lesquels le réseau est inactif : aucune requête en cours, et pourtant la page n’est pas prête. Presque toujours, cela signifie que le goulot d’étranglement n’est pas le réseau mais le processeur : le navigateur exécute du JavaScript, calcule des styles ou affiche, et ne peut ni découvrir ni demander de nouvelles ressources. Dans WebPageTest, le graphique d’utilisation du processeur sous le waterfall le confirme d’un coup d’œil ; dans DevTools, le panneau Performances montre quelles tâches occupent le thread principal à ce moment-là.
7. Quelles ressources sont trop volumineuses ?
Les barres avec une longue phase de téléchargement indiquent des ressources lourdes. Trier le panneau Réseau par taille fait vite apparaître des images non optimisées, d’énormes bundles JavaScript, des polices complètes dont on n’a pas extrait de sous-ensemble, des vidéos en lecture automatique. Il vaut aussi la peine de consulter la colonne qui compare la taille transférée à la taille réelle : si elles sont égales pour un fichier texte, la compression est absente.
8. Que se passe-t-il ensuite ?
Ce qui se passe après l’événement load mérite lui aussi un coup d’œil. Scripts d’analytics, pixels, chat, cartes de chaleur, requêtes périodiques : ils ne retardent pas le premier chargement, mais ils prennent de la bande passante et du temps de processeur juste au moment où l’utilisateur commence à interagir, avec des effets sur l’INP. Une longue traîne de requêtes tierces après le chargement est le signe qu’il vaut la peine de revoir vos scripts tiers.
Les colonnes utiles
Dans le panneau Réseau de DevTools, certaines colonnes non visibles par défaut rendent la lecture bien plus efficace. On les ajoute par un clic droit sur l’en-tête du tableau.
- Priorité : la priorité attribuée par le navigateur, utile pour vérifier que l’image LCP et le CSS critique ont une priorité élevée.
- Initiateur : qui a demandé la ressource, le HTML, une feuille de style ou un script, indispensable pour reconstituer les chaînes.
- Protocole : HTTP/1.1, HTTP/2 ou HTTP/3, pour vérifier que les connexions utilisent des protocoles modernes.
- Taille, avec la taille transférée et la taille réelle, et les en-têtes de réponse comme
Content-EncodingetCache-Control.
En survolant une barre du waterfall, DevTools affiche le détail exact des phases avec leurs durées, et dans l’onglet Timing de chaque requête les mêmes données apparaissent sous forme détaillée. Dans WebPageTest, un clic sur une ligne ouvre le détail complet de la requête et de la réponse, avec tous les en-têtes.
Première visite et visite répétée
Le waterfall d’une première visite, avec un cache vide, et celui d’une visite répétée racontent des histoires différentes. WebPageTest produit les deux. Dans la visite répétée, de nombreuses ressources devraient disparaître ou apparaître comme des réponses du cache du navigateur : si elles sont téléchargées de nouveau, les en-têtes de cache ne sont pas configurés correctement. Les requêtes qui apparaissent avec une réponse 304 indiquent des ressources revalidées auprès du serveur, un mécanisme utile qui coûte tout de même un aller-retour réseau, comme l’explique l’article sur HTTP 304 Not Modified.
Le waterfall comme outil de vérification
Au-delà du diagnostic, le waterfall est le meilleur moyen de vérifier une modification. Un preload doit déplacer vers la gauche la ressource à laquelle il s’applique ; un fetchpriority doit changer sa priorité ; supprimer un domaine doit faire disparaître une séquence de connexion ; un CSS critique doit avancer la ligne du premier affichage. Comparer les waterfalls avant et après, dans les mêmes conditions de test, montre si la modification a eu l’effet attendu et si elle a eu des effets secondaires, comme une ressource critique repoussée vers la droite parce qu’une autre lui a pris sa bande passante.
WebPageTest permet de comparer deux tests côte à côte, avec les waterfalls et les pellicules alignés. C’est aussi un outil de communication efficace : la pellicule d’une page qui se construit en une seconde à côté de celle de la même page qui en demandait auparavant quatre est plus convaincante que n’importe quel chiffre.
Les limites
Le waterfall décrit un seul chargement, dans des conditions précises : un appareil, un réseau, un lieu, un état du cache. C’est un outil de laboratoire, précieux pour comprendre les causes, mais il ne représente pas la variété des expériences réelles. Un problème que le waterfall ne montre pas peut quand même exister pour certains utilisateurs, et inversement. C’est pourquoi il faut toujours l’utiliser avec les données de terrain, comme l’explique l’article sur la raison pour laquelle CrUX et les tests de laboratoire sont tous deux nécessaires : les données d’utilisateurs réels vous disent où regarder, le waterfall vous dit ce qui se passe.
En résumé
Le waterfall montre chaque requête de la page dans le temps, avec ses phases : ouverture de la connexion, attente du serveur, téléchargement. Lu avec méthode, il répond aux questions qui comptent : combien de temps met le serveur, ce qui bloque le premier affichage, quand démarre la ressource LCP, où sont les chaînes, combien de domaines sont contactés, où le réseau est inactif parce que le processeur travaille, quelles ressources sont trop volumineuses et ce qui se passe après le chargement.
Les bonnes colonnes dans DevTools, la comparaison entre première visite et visite répétée dans WebPageTest et la comparaison avant-après de chaque modification en font l’outil de travail quotidien de quiconque s’occupe de performance. Apprendre à le lire prend quelques heures ; le temps qu’il fait gagner dans les analyses suivantes est bien supérieur.
