Visualizador de Arquivos HAR
Visualiza e analisa o conteúdo de arquivos HAR.
Visão geral
Um arquivo HAR é um registro em JSON de tudo o que o navegador carregou, exportado do DevTools. É preciso e praticamente ilegível a olho nu. Este visualizador o transforma de volta no waterfall que você estava olhando no DevTools, para que você consiga ler uma captura que alguém lhe mandou sem precisar abrir o navegador dessa pessoa.
Cada barra é dividida nas fases que o navegador de fato registrou: tempo bloqueado na fila, DNS, conexão, handshake TLS, espera pelo primeiro byte e download. Uma barra longa formada quase inteiramente por TTFB é um problema de servidor; uma barra longa formada quase inteiramente por download é um problema de payload.
Como usar
- No DevTools, abra Network, clique com o botão direito na lista de requisições e escolha Save all as HAR.
- Solte o arquivo aqui, ou clique para procurá-lo. Nada sai da página.
- Filtre por tipo de recurso e clique em uma linha para ver a URL dela e o detalhamento completo das fases.
- Leia TRANSFER BY TYPE para descobrir o que realmente domina o peso da página.
Lendo as fases
Os seis segmentos são registrados pelo navegador, não derivados por cálculo, e cada um aponta para um responsável diferente pelo problema.
| Fase | O que mede | De quem é a culpa quando é longa |
|---|---|---|
blocked | Enfileirada no navegador, esperando uma vaga de conexão | Da página — requisições paralelas em excesso, ou HTTP/1.1 |
dns | Resolução de nome | Do provedor de DNS, ou de um cache frio na primeira visita |
connect | Handshake TCP | Da distância de rede até a origem |
tls | Handshake TLS | Do tamanho da cadeia de certificados, ou da ausência de retomada de sessão |
ttfb | Espera depois de a requisição ter sido enviada | Do servidor. Quase sempre tempo de aplicação ou de banco de dados |
download | Recebimento do corpo | Do tamanho do payload, ou da banda disponível |
O valor -1 significa que o navegador não registrou aquela fase, o que é
normal: uma requisição que reaproveita uma conexão existente não tem dns,
connect nem tls nenhum. A ferramenta omite esses segmentos em vez de
desenhá-los como zero.
Vale aprender a identificar dois padrões. Uma linha em que blocked domina,
com muitas linhas compartilhando o mesmo host, é contenção de conexão — a
correção é reduzir requisições ou adotar HTTP/2, não um servidor mais rápido.
Uma linha em que ttfb domina na requisição do documento significa que todas as
outras barras da captura começam atrasadas; nada que venha depois pode ser mais
rápido do que esse número.
Lendo a forma do waterfall
A posição horizontal de cada barra importa tanto quanto a largura dela. As requisições são colocadas em uma linha de tempo compartilhada, então uma escada indica serialização: cada requisição não pôde começar antes de uma anterior terminar. As causas de sempre são uma folha de estilo que bloqueia a renderização, um script síncrono que bloqueia o parser, ou uma resposta JSON que contém as URLs da próxima rodada de requisições.
As marcas DCL e LOAD vêm dos próprios tempos de página da captura. As
requisições à direita de LOAD não afetaram o evento de load — imagens com
carregamento tardio, beacons de analytics, prefetches. As requisições à esquerda
de DCL estão no caminho crítico, quer você tenha planejado isso ou não.
O que é mascarado na tela
O visualizador mostra os valores de cabeçalhos e parâmetros para que você possa
depurar com eles, com uma exceção: valores cujos nomes parecem credenciais —
Cookie, Authorization, token, api_key, signature, code, state —
aparecem mascarados. Isso é proteção contra alguém olhando por cima do seu
ombro, não uma fronteira de segurança. O arquivo no seu disco continua
inalterado e ainda contém todos os segredos.
Se você precisa de uma versão para anexar a uma issue ou mandar a um fornecedor, use o sanitizador HAR. Ele reescreve o JSON — limpando os arrays de cookies, os corpos de requisição e de resposta, os destinos de redirecionamento e os frames WebSocket — e devolve um arquivo seguro para compartilhar.
Exemplos
- Primeira pintura lenta: procure um segmento TTFB largo na requisição do documento — o custo está no servidor, não na rede.
- Página pesada demais: a barra de transferência normalmente deixa óbvio que as imagens ou um único bundle de JS respondem pela maior parte dos bytes.
- Deploy quebrado: filtre por
jse procure 404 que sobraram de uma referência desatualizada. - Um terceiro de que você tinha esquecido: ordene por host no detalhamento de transferência. Gerenciadores de tag tendem a trazer mais coisa do que quem os instalou esperava.
- «Rápido para mim, lento para o usuário»: compare a captura dele com a sua.
Diferenças em
dnseconnectsão geografia; diferenças emttfbno mesmo endpoint normalmente são estado de cache.
Observações
Os tamanhos vêm do tamanho transferido registrado na captura quando ele existe, com fallback para corpo mais cabeçalhos e, depois, para o tamanho do conteúdo decodificado — nessa ordem, porque exportadores diferentes preenchem campos diferentes.
O tipo de recurso é inferido primeiro pela extensão na URL e só depois pelo tipo
MIME, porque uma página de erro devolve text/html mesmo para uma requisição
que deveria ser um script.
Capturas de navegadores diferentes não são diretamente comparáveis. Firefox e
Safari preenchem campos opcionais distintos, e o Chrome acrescenta as entradas
não padronizadas _initiator e _webSocketMessages. Este visualizador lê os
campos padrão e ignora o resto, de modo que uma captura do Firefox é renderizada
com menos detalhe em vez de falhar.
Se você não tem uma captura à mão, load sample capture abre um HAR sintético pequeno para você ver como o painel se lê. São dados de demonstração, marcados como tal no cabeçalho — não uma medição real.