Paramètres du panneau Network de Chrome DevTools pour les Core Web Vitals
Les paramètres du panneau Network que j'utilise à chaque audit Core Web Vitals

Le panneau Network de Chrome DevTools est l'un des outils les plus utiles pour déboguer les Core Web Vitals. Mais les paramètres par défaut masquent la moitié des informations dont vous avez besoin. Voici comment je configure le panneau Network à chaque audit.
Dernière révision par Arjen Karel en mars 2026
Table of Contents!
Configuration du panneau Network
Pour accéder au panneau Network, ouvrez Chrome DevTools (F12 ou Ctrl+Maj+I) et cliquez sur l'onglet "Network".

Throttling
Vos visiteurs ne sont pas sur le Wi-Fi de votre bureau. À l'échelle mondiale, 30 % des connexions mobiles sont encore en 3G et 55 % en 4G (GSMA Mobile Economy 2025). Le throttling du réseau vous permet de voir ce qu'ils voient.
Cliquez sur la liste déroulante "No throttling" dans le panneau Network. Sélectionnez "Fast 4G", "Slow 4G" ou "3G" pour simuler les conditions d'un réseau mobile. La meilleure option dépend de votre audience. Si votre audience utilise généralement des appareils mobiles haut de gamme dans des conditions de réseau rapides, activez "Fast 4G". Si les conditions de réseau typiques sont un peu moins bonnes, sélectionnez "Slow 4G". Sinon, jouez la sécurité et sélectionnez "3G".

Throttling des requêtes individuelles (Chrome 145+)
Depuis décembre 2025, vous pouvez appliquer un throttling à une seule requête au lieu de toute la page. Faites un clic droit sur n'importe quelle requête dans le panneau Network et sélectionnez "Throttle request." Cela vous permet de répondre à des questions comme : qu'arrive-t-il à mon LCP si ce script tiers se charge lentement ? Ou : comment ma page se comporte-t-elle lorsque le CDN est lent mais que la connexion de l'utilisateur est rapide ? C'est le moyen le plus rapide d'isoler l'impact sur les performances d'une seule ressource.
Désactiver le cache
Pour vous assurer de tester votre site tel qu'un visiteur novice le découvrirait, cochez la case "Disable cache" dans le panneau Network.

Activer les grandes lignes de requêtes
Les grandes lignes de requêtes affichent des détails critiques que la vue compacte par défaut masque :
- La colonne size indique à la fois la taille compressée (transfert) et la taille décompressée (réelle) de chaque requête.
- La colonne name affiche le chemin complet, et pas seulement le nom du fichier.
- La colonne priority montre la priorité de récupération (fetch priority) initiale et finale. C'est ainsi que vous vérifiez que votre image LCP se charge avec une priorité élevée (High) ou que vous repérez quand Chrome modifie la priorité d'une ressource.

Activer les captures d'écran
Activez les captures d'écran et Chrome enregistre une pellicule de chaque changement visuel pendant le chargement de la page. C'est ainsi que vous repérez les décalages de mise en page et vérifiez que votre élément LCP s'affiche au moment prévu.
- Avec l'onglet Network en surbrillance, appuyez sur Ctrl+F5 (Cmd+R sur Mac) pour rafraîchir la page.
- Chrome capturera des captures d'écran pendant le processus de chargement de la page.
- Des miniatures de ces captures d'écran apparaîtront sous la ligne de cases à cocher dans le panneau Network.
L'aperçu des captures d'écran possède quelques petites fonctionnalités pratiques que vous ne connaissez peut-être pas encore :
- Survolez une capture d'écran pour voir à quel moment elle a été prise. Cela sera indiqué par une ligne verticale jaune sur le graphique Overview.
- Cliquez sur la miniature d'une capture d'écran pour filtrer les requêtes survenues après la prise de cette capture d'écran.
- Double-cliquez sur une miniature pour zoomer et voir la capture d'écran plus en détail.

Activer les meilleures colonnes du panneau Network
Les colonnes par défaut manquent de données critiques. Faites un clic droit sur n'importe quel en-tête de colonne pour en ajouter d'autres. Voici celles que j'active à chaque audit :

| Nom de la colonne | Description | Pourquoi c'est important pour les Core Web Vitals |
|---|---|---|
| Name | Nom de la requête | Identifier chaque ressource que le navigateur télécharge |
| Status | Codes d'état HTTP | Repérer les redirections (301, 302) qui ajoutent de la latence à votre TTFB, et les erreurs 404 pour les ressources qui gaspillent un aller-retour réseau |
| Protocol | Protocole réseau utilisé | HTTP/3 élimine le blocage en tête de file (head-of-line blocking). Selon Cloudflare Radar, seulement 21 % des requêtes utilisent HTTP/3. Si votre CDN le supporte et que vous ne voyez pas h3 dans cette colonne, vérifiez votre configuration DNS |
| Domain | Domaine de la ressource | Séparer les requêtes first-party des requêtes tierces. Le Web Almanac 2024 a révélé que 92 % des pages chargent au moins une ressource tierce. Le tri par domaine révèle quelle proportion de votre cascade (waterfall) échappe à votre contrôle |
| Type | Type de ressource | Filtrer par type pour isoler les scripts, les images ou les polices qui se disputent la bande passante |
| Initiator | Déclencheur de la requête | Découvrir quel script ou feuille de style a déclenché chaque requête. C'est ainsi que vous pouvez remonter à la source d'une chaîne lente de requêtes critiques |
| Size | Taille réelle et transférée | Repérer les ressources non compressées ou surdimensionnées. La page mobile médiane charge 66 requêtes totalisant 2,3 Mo (Web Almanac 2024) |
| Priority | Priorité de chargement de la ressource | Affiche la priorité de récupération (fetch priority) initiale et finale. Vérifiez que votre image LCP se charge en priorité High (élevée) et que les scripts non critiques se chargent en Low (basse) |
| Waterfall | Chronologie visuelle des requêtes | La chronologie qui montre où le temps est passé. Les longues barres avant le premier affichage affectent directement votre LCP et FCP |
Activer les en-têtes de réponse personnalisés
| Nom de la colonne | Description | Pourquoi c'est important pour les Core Web Vitals |
|---|---|---|
| Cache-Control | Comportement de mise en cache de la ressource | Vérifier que les actifs statiques ont de longues durées de vie en cache et que le code HTML dispose d'une revalidation appropriée. Une mauvaise mise en cache force les visiteurs récurrents à retélécharger les ressources, ce qui nuit à chaque métrique. Voir aussi : Configuration du cache Cloudflare |
| Link | En-tête de réponse Link | Vérifier si votre serveur envoie des indications de preload ou preconnect, y compris via les 103 Early Hints |
| Content-Encoding | L'encodage utilisé | Vérifier que votre serveur envoie du Brotli (br) au lieu de gzip. Brotli compresse le JavaScript de 15 à 20 % de plus que gzip. Le Web Almanac 2024 montre que Brotli a dépassé gzip pour les ressources JavaScript (45 % contre 41 %) |
Si vous souhaitez analyser les en-têtes de réponse en masse sans ouvrir DevTools pour chaque page, essayez le HTTP Header Performance Analyzer.
Se connecter au panneau Performance
Le panneau Network vous montre ce qui se charge et quand. Pour voir comment chaque ressource affecte les Core Web Vitals, passez au panneau Performance. Il affiche désormais les scores LCP, CLS et INP en direct sans enregistrement et peut superposer les données de terrain CrUX des utilisateurs réels. Utilisez le panneau Network pour diagnostiquer, le panneau Performance pour confirmer.
Pour une surveillance continue au-delà d'une simple session de débogage, connectez un outil de Real User Monitoring afin de pouvoir suivre si vos correctifs dans le panneau Network améliorent réellement les données de terrain au fil du temps.
La configuration complète
Rechargez la page avec ces paramètres et votre panneau Network ressemblera à ceci. Chaque colonne correspond à un élément qui affecte les Core Web Vitals.

Performance degrades unless you guard it.
I do not just fix the metrics. I set up the monitoring, the budgets, and the processes so your team keeps them green after I leave.
Start the Engagement
