Réglages du panneau Network des Chrome DevTools pour les Core Web Vitals
Les réglages du panneau Network que j'utilise à chaque audit des Core Web Vitals
Partager
Le panneau Network des Chrome DevTools est l'un des outils les plus utiles pour déboguer les Core Web Vitals. Mais les réglages par défaut masquent la moitié des informations nécessaires. Voici comment je configure le panneau Network à chaque audit.
Dernière révision par Arjen Karel en mars 2026
Configurer le panneau Network
Pour accéder au panneau Network, ouvrez les Chrome DevTools (F12 ou Ctrl+Shift+I) et cliquez sur l'onglet « Network ».
Throttling
Vos visiteurs ne sont pas sur le Wi-Fi du bureau. À l'échelle mondiale, 30 % des connexions mobiles se font encore en 3G et 55 % en 4G (GSMA Mobile Economy 2025). Le throttling réseau vous montre ce qu'ils voient.
Cliquez sur le menu déroulant « No throttling » dans le panneau Network. Sélectionnez « Fast 4G », « Slow 4G » ou « 3G » pour simuler les conditions d'un réseau mobile. Le meilleur choix dépend de votre audience. Si vos visiteurs utilisent surtout des appareils haut de gamme sur un réseau rapide, activez « Fast 4G ». Si les conditions réseau moyennes sont un peu moins bonnes, choisissez « Slow 4G ». Sinon, jouez la sécurité et sélectionnez « 3G ».
Throttler des requêtes individuelles (Chrome 145+)
Depuis décembre 2025, vous pouvez throttler une seule requête au lieu de toute la page. Faites un clic droit sur une requête dans le panneau Network et sélectionnez « Throttle request ». Cela permet de répondre à des questions concrètes : que devient le LCP si ce script tiers charge lentement ? Ou encore : comment la page réagit-elle quand le CDN est lent mais que la connexion de l'utilisateur est rapide ? C'est le moyen le plus rapide d'isoler l'impact d'une seule ressource sur les performances.
Désactiver le cache
Pour tester votre site dans les conditions d'une première visite, 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 essentiels que la vue compacte par défaut masque :
- La colonne size affiche à la fois la taille compressée (transférée) et la taille décompressée (réelle) de chaque requête.
- La colonne name affiche le chemin complet, pas seulement le nom de fichier.
- La colonne priority affiche la fetch priority initiale et finale. C'est ainsi que vous vérifiez que l'image LCP charge avec une priorité High ou que vous repérez quand Chrome réévalue la priorité d'une ressource.
Activer les captures d'écran
Activez les captures d'écran et Chrome enregistrera un filmstrip de chaque changement visuel pendant le chargement de la page. C'est ainsi que vous repérez les layout shifts et vérifiez que l'élément LCP s'affiche au moment prévu.
- Avec l'onglet Network au premier plan, appuyez sur Ctrl+F5 (Cmd+R sur Mac) pour recharger la page.
- Chrome prendra des captures d'écran tout au long du chargement.
- Les vignettes de ces captures s'affichent sous la rangée de cases à cocher dans le panneau Network.
La vue d'ensemble des captures d'écran propose quelques fonctionnalités pratiques que vous ne connaissez peut-être pas :
- Survolez une capture d'écran pour voir à quel moment elle a été prise. Une ligne verticale jaune apparaît sur le graphique Overview.
- Cliquez sur une vignette pour masquer les requêtes intervenues après cette capture.
- Double-cliquez sur une vignette pour zoomer et afficher la capture en détail.
Activer les meilleures colonnes Network
Les colonnes par défaut omettent des informations critiques. Faites un clic droit sur l'en-tête d'une colonne pour en ajouter d'autres. Voici celles que j'active à chaque audit :
| Nom de la colonne | Description | Importance pour les Core Web Vitals |
|---|---|---|
| Name | Nom de la requête | Identifier chaque ressource téléchargée par le navigateur |
| Status | Codes de statut HTTP | Repérer les redirections (301, 302) qui ajoutent de la latence au TTFB, et les erreurs 404 de ressources qui gaspillent un aller-retour réseau |
| Protocol | Protocole réseau utilisé | HTTP/3 élimine le blocage en tête de ligne (head-of-line blocking). D'après Cloudflare Radar, seulement 21 % des requêtes utilisent HTTP/3. Si votre CDN le prend en charge et que vous ne voyez pas h3 dans cette colonne, vérifiez votre configuration DNS |
| Domain | Domaine de la ressource | Distinguer les requêtes first-party des requêtes tierces. Le Web Almanac 2024 montre que 92 % des pages chargent au moins une ressource tierce. Trier par domaine révèle quelle part de la waterfall échappe à votre contrôle |
| Type | Type de ressource | Filtrer par type pour isoler les scripts, images ou polices qui se disputent la bande passante |
| Initiator | Déclencheur de la requête | Identifier quel script ou quelle feuille de style a déclenché chaque requête. C'est ainsi que vous remontez à la source d'une chaîne lente de requêtes critiques |
| Size | Taille transférée et réelle | Repérer les ressources non compressées ou surdimensionnées. Sur mobile, la page médiane charge 66 requêtes pour un total de 2,3 Mo (Web Almanac 2024) |
| Priority | Priorité de chargement de la ressource | Affiche la fetch priority initiale et finale. Vérifiez que l'image LCP charge en High et les scripts non critiques en Low |
| Waterfall | Chronologie visuelle des requêtes | La frise chronologique qui montre où passe le temps. De longues barres avant le premier affichage impactent directement le LCP et le FCP |
Activer les en-têtes de réponse personnalisés
| Nom de la colonne | Description | Importance pour les Core Web Vitals |
|---|---|---|
| Cache-Control | Comportement de mise en cache de la ressource | Vérifier que les ressources statiques ont une durée de vie en cache longue et que le HTML applique une révalidation adaptée. Une mauvaise mise en cache force les visiteurs récurrents à retélécharger les ressources, ce qui dégrade l'ensemble des métriques. Voir aussi : configuration du cache Cloudflare |
| Link | En-tête de réponse Link | Vérifier si le serveur envoie des directives preload ou preconnect, notamment via 103 Early Hints |
| Content-Encoding | Encodage utilisé | Vérifier que le serveur envoie bien du Brotli (br) plutôt que du gzip. Brotli compresse le JavaScript 15 à 20 % de mieux que gzip. Le Web Almanac 2024 montre que Brotli a dépassé gzip pour les ressources JavaScript (45 % contre 41 %) |
Pour analyser les en-têtes de réponse en masse sans ouvrir les DevTools sur chaque page, testez l'HTTP Header Performance Analyzer.
Faire le lien avec le panneau Performance
Le panneau Network montre ce qui charge et quand. Pour comprendre comment chaque ressource affecte les Core Web Vitals, passez au panneau Performance. Il affiche désormais en direct les scores LCP, CLS et INP sans enregistrement préalable, et peut superposer les field data CrUX issues de vrais utilisateurs. Utilisez le panneau Network pour diagnostiquer, et le panneau Performance pour confirmer.
Pour un suivi continu au-delà d'une simple session de débogage, connectez un outil de Real User Monitoring afin de vérifier si vos optimisations dans le panneau Network améliorent réellement les field data dans le temps.
La configuration complète
Rechargez la page avec ces réglages. Voici à quoi ressemble désormais le panneau Network. Chaque colonne correspond à un élément qui influe sur les Core Web Vitals.
Besoin d'un site plus rapide ?
Je suis Arjen et je répare des sites lents depuis 17 ans. Si vous rencontrez des problèmes que vous ne pouvez pas résoudre vous-même, envoyez-moi votre URL et parlons-en.
Envoyez-moi votre URLPourquoi notre fix ne fonctionne pas ?
Parfois le CDN sert encore l'ancien HTML, ou le fix a été appliqué sur le template desktop alors que le mobile en utilise un autre. Envoyez-moi votre URL et le problème, et je vous réponds avec quelques créneaux. J'analyse d'abord vos field data, puis nous passons une heure sur votre site, et sous 24 heures vous avez mes notes par écrit. 350 € HT.
Envoyez-moi votre URLPas de développeur pour réaliser le fix ? Je fais le travail moi-même, sur une copie de votre site.