Visionneuse de Fichiers HAR

Visualise et analyse le contenu des fichiers HAR.

❯ har

drop a .har capture here — or click to browseDevTools → Network → right-click → “Save all as HAR”parsed in this tab · captures often hold cookies and tokens — they stay here

§01 À PROPOS DE CET OUTIL

Vue d’ensemble

Un fichier HAR est un relevé JSON de tout ce que le navigateur a chargé, exporté depuis les DevTools. Il est précis et quasiment illisible à l’œil nu. Ce visualiseur le retransforme en la cascade que vous regardiez dans les DevTools, afin que vous puissiez lire une capture envoyée par quelqu’un d’autre sans ouvrir son navigateur.

Chaque barre est découpée selon les phases que le navigateur a réellement enregistrées : temps bloqué dans la file d’attente, DNS, établissement de la connexion, poignée de main TLS, attente du premier octet, et téléchargement. Une barre longue presque entièrement composée de TTFB est un problème de serveur ; une barre longue presque entièrement composée de téléchargement est un problème de charge utile.

Utilisation

Dans les DevTools, ouvrez Network, faites un clic droit sur la liste des requêtes et choisissez Save all as HAR.
Déposez le fichier ici, ou cliquez pour parcourir. Rien ne quitte la page.
Filtrez par type de ressource, et cliquez sur une ligne pour voir son URL et le détail complet de ses phases.
Lisez TRANSFER BY TYPE pour découvrir ce qui pèse vraiment dans la page.

Lire les phases

Les six segments sont enregistrés par le navigateur, non déduits, et chacun désigne un responsable différent du problème.

Phase	Ce qu’elle mesure	À qui incombe une phase longue
`blocked`	En file d’attente dans le navigateur, à attendre un créneau de connexion	La page — trop de requêtes en parallèle, ou HTTP/1.1
`dns`	Résolution du nom	Le fournisseur DNS, ou un cache froid à la première visite
`connect`	Poignée de main TCP	La distance réseau jusqu’à l’origine
`tls`	Poignée de main TLS	La longueur de la chaîne de certificats, ou l’absence de reprise de session
`ttfb`	Attente après l’envoi de la requête	Le serveur. Presque toujours du temps applicatif ou de base de données
`download`	Réception du corps	La taille de la charge utile, ou la bande passante

Une valeur de -1 signifie que le navigateur n’a pas enregistré cette phase, ce qui est normal : une requête qui réutilise une connexion existante n’a aucun dns, connect ni tls. L’outil omet ces segments plutôt que de les dessiner à zéro.

Deux motifs valent la peine d’apprendre à les repérer. Une ligne où blocked domine, alors que de nombreuses lignes partagent le même hôte, signale une contention de connexions — le remède est de réduire le nombre de requêtes ou de passer à HTTP/2, pas d’accélérer le serveur. Une ligne où ttfb domine sur la requête du document signifie que toutes les autres barres de la capture démarrent en retard ; rien en aval ne peut être plus rapide que ce nombre.

Lire la forme de la cascade

La position horizontale de chaque barre importe autant que sa largeur. Les requêtes sont placées sur une frise chronologique commune, donc un escalier signale une sérialisation : chaque requête n’a pu démarrer qu’une fois la précédente terminée. Les causes habituelles sont une feuille de style qui bloque le rendu, un script synchrone qui bloque l’analyseur, ou une réponse JSON qui contient les URL de la vague de requêtes suivante.

Les repères DCL et LOAD proviennent des mesures de temps de page contenues dans la capture. Les requêtes situées à droite de LOAD n’ont pas affecté l’événement de chargement — images en chargement paresseux, balises de mesure d’audience, préchargements. Celles situées à gauche de DCL sont sur le chemin critique, que vous l’ayez voulu ou non.

Ce qui est masqué à l’écran

Le visualiseur affiche les valeurs des en-têtes et des paramètres pour que vous puissiez déboguer avec, à une exception près : les valeurs dont le nom ressemble à un identifiant — Cookie, Authorization, token, api_key, signature, code, state — sont affichées masquées. C’est une protection contre le regard par-dessus l’épaule, pas une frontière de sécurité. Le fichier sur votre disque est inchangé et contient toujours chaque secret.

S’il vous faut une version que vous puissiez joindre à un ticket ou envoyer à un fournisseur, utilisez l’assainisseur HAR. Il réécrit le JSON — en vidant les tableaux de cookies, les corps de requête et de réponse, les cibles de redirection et les trames WebSocket — et vous rend un fichier qu’il est sûr de partager.

Exemples

Premier affichage lent : cherchez un large segment TTFB sur la requête du document — le coût vient du serveur, pas du réseau.
Page trop lourde : la barre de transfert rend en général évident que les images ou un unique paquet JS représentent l’essentiel des octets.
Déploiement cassé : filtrez sur js et cherchez des 404 restés en place à cause d’une référence périmée.
Un tiers que vous aviez oublié : triez par hôte dans la répartition des transferts. Les gestionnaires de balises ont tendance à embarquer plus de choses que ne l’imaginait la personne qui les a ajoutés.
« Rapide chez moi, lent chez l’utilisateur » : comparez sa capture à la vôtre. Les écarts sur dns et connect sont une question de géographie ; les écarts sur ttfb pour le même point d’entrée relèvent en général de l’état du cache.

Remarques

Les tailles proviennent de la taille de transfert enregistrée dans la capture lorsqu’elle est présente, à défaut du corps plus les en-têtes, puis de la taille du contenu décodé — dans cet ordre, parce que les différents exportateurs remplissent des champs différents.

Le type de ressource est déduit d’abord de l’extension dans l’URL, ensuite du type MIME, parce qu’une page d’erreur renvoie text/html même pour une requête censée récupérer un script.

Les captures issues de navigateurs différents ne sont pas directement comparables. Firefox et Safari remplissent des champs optionnels différents, et Chrome ajoute les entrées non standard _initiator et _webSocketMessages. Ce visualiseur lit les champs standard et ignore le reste, si bien qu’une capture Firefox s’affiche avec moins de détail plutôt qu’en échec.

Si vous n’avez pas de capture sous la main, load sample capture ouvre un petit HAR synthétique pour vous montrer comment se lit le panneau. Ce sont des données de démonstration, étiquetées comme telles dans l’en-tête — pas une mesure réelle.

FAQ

Ma capture est-elle envoyée quelque part ?

Non. Le fichier est lu avec le FileReader du navigateur et analysé dans la page. Rien n'est transmis à un serveur. Cela compte plus que d'habitude ici — les captures HAR contiennent couramment des cookies, des en-têtes Authorization et des jetons de session.

Que signifient les couleurs dans chaque barre ?

Ce sont les mesures de temps HAR de la requête, dans l'ordre — blocked, dns, connect, tls, ttfb (attente) et download (réception). Les largeurs sont les valeurs enregistrées, exprimées en proportion du temps total de cette requête, et non des estimations.

Pourquoi une requête n'affiche-t-elle aucune taille, ou bien « cache » ?

Le format HAR n'enregistre la taille du transfert que lorsque le navigateur la connaît. Une requête servie depuis le cache HTTP ne transfère aucun octet sur le réseau, donc l'outil affiche « cache » plutôt que d'inventer un nombre.

D'où viennent les lignes DCL et LOAD ?

Des mesures de temps de page contenues dans la capture elle-même (onContentLoad et onLoad). Si le HAR n'a pas de section pages — certains exportateurs l'omettent — les repères ne sont tout simplement pas tracés.

Puis-je partager la capture après l'avoir consultée ici ?

Pas en l'état. Ce visualiseur masque les secrets à l'écran mais ne modifie pas le fichier. Passez-le d'abord par l'[assainisseur HAR](/fr/har-sanitizer/), qui réécrit le JSON et vous rend une version qu'il est sûr de joindre.