← Tous les articles

Fenêtres sur le frontend

Un panneau réseau sans DevTools — l'onglet Network de JustZix

16 mai 2026 · par JustZix Team

Le panneau Network des DevTools a un défaut tenace : il n'enregistre que pendant qu'il est ouvert. Rafraîchissez, oubliez de l'ouvrir d'abord, et la requête dont vous aviez besoin a disparu. L'Output Console de JustZix dispose d'un onglet Network qui vit à l'intérieur de la page, capture le trafic via chrome.webRequest, et conserve un buffer d'arrière-plan — il voit donc les requêtes qui se sont déclenchées avant que vous ouvriez la fenêtre. Voici comment cela fonctionne et où cela trouve sa place.

Comment fonctionne la capture : chrome.webRequest

L'onglet Network n'intercepte pas fetch ou XMLHttpRequest dans le code de la page. Il utilise chrome.webRequest — une API au niveau du navigateur que l'extension exploite via la permission webRequest du manifeste. Cela signifie qu'il observe les requêtes au niveau du navigateur, au même endroit que la pile réseau.

La conséquence pratique est la fonctionnalité phare : un buffer d'arrière-plan. L'extension conserve un enregistrement courant des requêtes pour l'onglet. Quand vous ouvrez l'Output Console, l'onglet Network est déjà rempli de ce qui s'est passé avant que vous y arriviez. Plus de danse « rafraîchir pour capturer ».

Ouvrir l'onglet Network

Ouvrez l'Output Console depuis le menu du bouton flottant de JustZix, ou en fenêtre TEMP avec Ctrl+Alt+K, puis basculez sur l'onglet Network. Son badge affiche le nombre de requêtes en direct. Grâce au buffer, la liste n'est pas vide même sur une page que vous avez chargée il y a quelques minutes.

Ce que signifie chaque colonne

Chaque requête capturée est une ligne. Les colonnes :

Method, status et URL vous disent ce qui s'est passé. Size et duration vous disent combien cela a coûté. Remote address et Initiator vous disent où elle est allée et qui l'a lancée — les deux colonnes qui comptent le plus quand vous traquez une requête que vous n'avez pas écrite vous-même.

La barre de filtres contextuelle — trois rangées

La barre de filtres de l'Output Console est contextuelle ; sur l'onglet Network, elle s'étend en trois rangées de contrôles :

1. Type de ressource — une rangée de cases à cocher : document, script, feuille de style, image, xhr/fetch, police, et plus. Décochez les types qui ne vous intéressent pas. Vous déboguez une API ? Gardez seulement xhr/fetch et le bruit des images et des polices disparaît.
2. Classe de statut HTTP — une rangée de cases à cocher par classe : 2xx, 3xx, 4xx, 5xx. Décochez 2xx et 3xx pour ne voir que les échecs.
3. Taille + durée + domaine — deux curseurs de plage (0–100000, durée en millisecondes) plus un champ de filtre de domaine.

Les rangées de cases à cocher disposent de raccourcis tout sélectionner / tout effacer, vous pouvez ainsi tout effacer et cocher le seul type que vous voulez, ou l'inverse — pas besoin de cliquer dans dix cases à la main.

Les curseurs et le filtre de domaine

Les curseurs de plage transforment un soupçon vague en une requête précise :

• Curseur de durée — fixez un minimum et seules les requêtes lentes survivent. Faites-le glisser jusqu'à 2000 ms et vous obtenez une liste de tout ce qui a pris plus de deux secondes.
• Curseur de taille — même idée pour les octets. Fixez un plancher et les charges utiles surdimensionnées — l'image principale non optimisée, le blob JSON de 400 Ko — remontent en haut.
• Filtre de domaine — tapez un fragment de domaine pour ne garder que les requêtes vers cet hôte. Tapez google-analytics ou doubleclick et vous regardez exactement le trafic tiers que vous vouliez auditer.

Tout cela se cumule avec la zone de recherche toujours visible sous la barre de filtres — un filtre de sous-chaîne en direct, insensible à la casse, sur les lignes. Échap efface la recherche.

Cas d'usage 1 — déboguer les appels d'API

Effacez la rangée de type de ressource, cochez seulement xhr/fetch. Maintenant l'onglet Network n'est que le trafic d'API de votre application — pas de scripts, pas d'images. Déclenchez l'action que vous déboguez et observez la requête apparaître : method, URL, status, combien de temps elle a pris. Si le statut est faux, vous savez immédiatement si le problème est la requête ou le code qui gère la réponse.

Cas d'usage 2 — trouver les requêtes lentes ou surdimensionnées

Faites glisser le curseur de durée jusqu'à un seuil — disons 1500 ms — et la liste se réduit à vos requêtes les plus lentes. Faites de même avec le curseur de taille pour faire ressortir les charges utiles lourdes. Deux glissements et vous avez une liste restreinte de performance : les requêtes qui valent réellement la peine d'être optimisées, triées parmi les dizaines qui vont bien.

Cas d'usage 3 — repérer les échecs 4xx et 5xx

C'est ce que l'onglet Errors ne peut pas faire pour vous. Un fetch ou XHR échoué n'est pas une exception JavaScript — il n'atteint jamais l'onglet Errors. Pour trouver les requêtes cassées, venez sur l'onglet Network et décochez 2xx et 3xx dans la rangée de statut. Ce qui reste, c'est chaque 4xx et 5xx : le point de terminaison manquant, l'échec d'authentification, l'erreur serveur. Ajoutez un terme de recherche pour cibler un chemin.

Cas d'usage 4 — auditer les traceurs tiers et les beacons

Chaque site charge des choses qu'il n'a pas nécessairement annoncées — analytique, pixels publicitaires, beacons. Tapez un domaine de traceur dans le filtre de domaine, ou observez la colonne Initiator pour voir quel script a déclenché quel beacon. Combinée à la colonne Remote address, vous pouvez dire exactement où vont les données. C'est un audit de confidentialité rapide et honnête sans aucun outillage spécialisé.

Comparaison honnête avec le panneau Network des DevTools

Le panneau Network des DevTools est plus puissant — cet onglet ne prétend pas le contraire. Mais les compromis sont réels et ils tranchent dans les deux sens :

La limitation décisive : chrome.webRequest fournit les métadonnées de requête, pas les corps des réponses. Si vous devez lire le JSON qu'une requête a renvoyé, les DevTools restent votre outil. Si vous devez savoir quelles requêtes se sont déclenchées, si elles ont réussi, à quel point elles étaient lentes, et où elles sont allées — y compris les requêtes d'avant que vous commenciez à regarder — l'onglet Network le fait dans l'onglet, sans aucun DevTools.

Quand recourir à quoi

• Onglet Network — triage rapide, machines verrouillées, capturer les requêtes déclenchées au chargement de la page, auditer le trafic tiers, partager une configuration de débogage dans le cadre d'une règle.
• Network des DevTools — inspecter les corps des réponses, lire les en-têtes, la cascade de timing, le throttling, rejouer les requêtes.

Ce ne sont pas des rivaux. L'onglet Network gère la question quotidienne « qu'est-ce que cette page fait sur le réseau » ; les DevTools gèrent la plongée approfondie.

À voir aussi

• L'Output Console repensée — les six onglets expliqués
• Exemples JustZix — des règles CSS et JS prêtes à l'emploi

Un panneau réseau qui capture depuis avant que vous l'ouvriez, directement dans l'onglet — pas de F12 requis. Téléchargez JustZix — c'est gratuit, ça tourne sur Chrome 100+, et l'installation prend environ deux minutes.