
Alguém te pediu para “abrir a aba de Rede e ver se alguma solicitação está falhando”, e agora você está olhando para um painel cheio de linhas, cores e colunas que ainda não significam nada. Este é o caminho mais curto de lá para a resposta que eles queriam.
A aba de Rede registra todas as solicitações que a página faz: todas as imagens, todos os scripts e todas as chamadas que seu navegador envia para um servidor para buscar dados. Quando uma página está com defeito de uma forma que você não consegue ver - um botão que não faz nada, uma lista que não carrega, um salvamento que falha silenciosamente - a razão é muito frequentemente uma dessas solicitações, e é aqui que está escrito.
Abrindo
Chrome, Edge, Brave e o resto do Chromium. Pressione F12, ou Cmd + Option + I em um Mac. As ferramentas do desenvolvedor se abrirão; clique na aba Rede no topo. Se você não a vir, ela está por trás da seta de estouro ».
Firefox. O mesmo F12, depois a aba Rede.
Safari. A aba de Rede fica atrás de um menu que está desativado por padrão. Abra Configurações, vá para Avançado e marque Mostrar recursos para desenvolvedores de web. Depois Desenvolver, Mostrar Inspetor de Web e a aba Rede está lá.
O painel quase sempre está vazio quando abre, e isso é a primeira coisa que confunde as pessoas.
Por que está vazio e como preenchê-la
A aba de Rede registra apenas enquanto está aberta. Ela não se lembra do que aconteceu antes de você chegar lá, então as solicitações que foram executadas quando a página carregou inicialmente já desapareceram.
Então: com a aba aberta, recarregue a página. Tudo o que a página buscar vai aparecer como uma lista de linhas. Se o problema acontecer quando você clica em algo em vez de no carregamento, você nem precisa recarregar - apenas faça a ação e observe as linhas aparecerem conforme você faz.
Uma configuração vale a pena ativar antes de começar: Preservar registro (Firefox chama da mesma forma). Sem ela, uma página que redireciona ou recarrega limpa a lista, e a solicitação que você estava perseguindo desaparece com ela. Com ela marcada, a lista sobrevive e você pode ver a solicitação que aconteceu logo antes da página mudar.
Lendo uma linha
Cada linha é uma solicitação. Da esquerda para a direita, as colunas que importam:
- Nome - o arquivo ou endpoint que foi solicitado
- Status - o código HTTP que voltou. Este é o que você foi enviado aqui para procurar
-
Tipo - que tipo de coisa era: um documento, um script, uma imagem, ou
fetch/xhrpara uma chamada de dados - Tempo - quanto tempo levou
As cores são um atalho. Uma linha vermelha é uma solicitação que falhou. Se alguém disse “veja se algo está falhando”, você está procurando por vermelho ou por um status de 400 ou superior.
Clique em qualquer linha e um painel abre com o detalhe: Cabeçalhos para o que foi enviado e recebido, Resposta ou Visualização para o que voltou e Cronometragem para onde o tempo se foi. Para uma solicitação falhando, Resposta é geralmente onde a explicação do servidor está.
O que XHR significa, porque é o filtro que você será instruído a usar
Ao longo da parte superior do painel há uma linha de filtros: Tudo, Fetch/XHR, Doc, CSS, JS, Img. “Abra a aba de Rede e filtre para XHR” é uma instrução comum, e XHR é a palavra menos óbvia nela.
XHR é a abreviação para XMLHttpRequest. Na prática, significa uma solicitação que sua página fez em segundo plano para buscar dados, sem carregar uma nova página - a forma moderna da web de atualizar parte de uma tela sem um recarregamento completo. Quando você digita em uma caixa de pesquisa e os resultados aparecem abaixo, isso é um XHR. Quando um botão “Carregar mais” adiciona itens sem a página piscar, esse é um XHR.
O nome é um acidente histórico - o recurso do navegador original foi construído para XML, que quase ninguém envia mais; hoje eles carregam JSON. Seu substituto mais novo é a função fetch(), e é por isso que o filtro lê Fetch/XHR: dois nomes, ambos significando a mesma coisa, uma solicitação de dados em vez de uma página, uma imagem ou uma folha de estilo.
Clicar em Fetch/XHR esconde as imagens, scripts e fontes e deixa apenas as chamadas de dados, que é quase sempre onde está a falha de um recurso quebrado. Um botão que não faz nada geralmente enviou uma solicitação; está bem lá, em vermelho, com a razão em sua Resposta.
Transformando em algo que você pode enviar
Ler a aba de Rede você mesmo é uma coisa. A parte mais difícil é levar o que você viu para a pessoa que pode corrigi-lo, porque uma captura de tela do painel perde o detalhe - os cabeçalhos, o corpo da resposta, a ordem - que realmente explica a falha.
A aba pode exportar a sessão inteira como um arquivo HAR: clique com o botão direito em qualquer linha e escolha Salvar tudo como HAR com conteúdo. Esse é o log de rede em um arquivo, que alguém pode abrir em sua própria aba de Rede, ou no visualizador HAR, exatamente como se tivesse registrado. Leia esse guia antes de enviar um - um HAR geralmente contém seus cookies de sessão e deve ser tratado como uma senha.
Se a solicitação falhando é aquela que retorna “TypeError: Failed to fetch” no console sem nada útil na aba de Rede, esse caso específico tem sua própria explicação - geralmente significa que a solicitação nunca chegou longe o suficiente para ter um status.
Session Replay
Extensão gratuita do Chrome. Um clique na página que está se comportando mal captura a screenshot, o console e o log de rede, e oferece a você um link para colar no ticket.
O log de rede que ela captura é a mesma lista de solicitações que você teria lido na aba, já salva e anexada, para que a pessoa que pega o relatório não tenha que conversar com você sobre abrir. Para tudo ao seu redor - o que você esperava e o que aconteceu em vez disso - o guia de relatório de bugs tem o modelo.