Como usar a ferramenta
- Mantenha a aba visível e evite outro teste de transferência. Selecione Iniciar para enviar 20 requisições HTTP pequenas ao site, com uma pausa curta entre elas.
- Espere a sequência terminar ou selecione Parar para cancelar. Requisições com falha ou canceladas não contam como leituras de zero milissegundos.
- Veja os tempos individuais junto com a média e a variação. Repita em condições semelhantes para comparar observações desse servidor.
Método de cálculo
Cada amostra inclui a requisição HTTP e sua resposta consumida e validada. O RTT médio é a soma dos tempos válidos dividida pela quantidade. A variação é a diferença absoluta média entre requisições consecutivas bem-sucedidas: soma de |próximo − anterior| ÷ pares válidos. Pares que atravessam uma requisição com falha são excluídos.
Exemplo de cálculo
Com 40, 60 e 50 ms, o RTT médio é 50 ms. As mudanças consecutivas são 20 e 10 ms, resultando em variação absoluta média de 15 ms. Três leituras de 40 ms têm variação zero, mas o atraso médio continua sendo 40 ms.
Escolher o caminho da medição
Os tempos pertencem ao caminho deste navegador até o servidor deste site. Incluem a conexão local, o trajeto pela Internet, o atendimento do servidor e o trabalho do navegador. O destino aparece durante a execução. Não existe seletor para medir um servidor de jogo, serviço de reunião ou roteador. Um resultado estável aqui pode coexistir com problemas em outro destino.
Anote o dispositivo, o tipo de conexão, o estado da VPN e o horário aproximado. Mantenha esses dados ao comparar execuções. Comparar Ethernet e Wi-Fi ajuda a investigar o trecho local, mas trocar também o dispositivo impede atribuir a diferença a uma única mudança. A ferramenta não localiza um salto com defeito nem certifica toda a rede da operadora.
Iniciar uma sequência limitada de solicitações
Abrir a página não inicia as medições. Leia o consentimento, marque a caixa e pressione Iniciar. A ferramenta envia vinte solicitações HTTP pequenas e sequenciais ao servidor do próprio site, esperando 250 ms entre tentativas. Cada resposta válida contém 32 bytes de teste. Cabeçalhos e estabelecimento da conexão acrescentam tráfego; vinte vezes 32 bytes não representa o total cobrado pela operadora.
Mantenha a página visível. Ocultar a aba interrompe a execução. Há um prazo para cada solicitação e outro para o teste inteiro, evitando uma espera indefinida. Parar cancela a solicitação ativa. Redefinir apaga os resultados e o consentimento. Uma nova execução substitui as amostras anteriores; copie um registro útil antes de comparar outra condição de conexão.
Separar tempos concluídos de falhas
Mínimo e máximo são a menor e a maior duração HTTP concluída. A média soma as durações válidas e divide pela quantidade. A mediana ordena os tempos e escolhe o central; uma quantidade par usa a média dos dois valores centrais. Uma tentativa com falha permanece na tabela e nunca recebe um tempo fictício de zero milissegundos.
Uma diferença grande entre média e mediana pode mostrar uma resposta muito demorada. Leia a ordem das amostras para encontrar o episódio. A primeira tentativa continua incluída; não existe descarte de uma fase de aquecimento. O início da conexão pode influenciar o resumo. São tempos HTTP vistos pelo cliente, não atraso em um sentido, ping ICMP ou uma medição direta do tempo de transmissão pelo rádio.
Entender a mudança entre amostras consecutivas
A variação é a média das diferenças absolutas entre amostras válidas adjacentes na ordem original. Para 20, 30 e 50 ms, as mudanças são 10 e 20 ms, com média de 15 ms. A duração média é aproximadamente 33,333 ms e a mediana é 30 ms. Atraso médio e variação descrevem aspectos diferentes da sequência.
Considere agora 20 ms, 30 ms, uma falha, 50 ms e 70 ms. Apenas os pares de 20 para 30 e de 50 para 70 entram no cálculo, mantendo a mudança média de 15 ms. O programa não une 30 a 50 atravessando a observação ausente. As quatro respostas válidas têm média de 42,5 ms e mediana de 40 ms. A falha continua visível.
A segunda linha corresponde à sequência com a terceira tentativa falha descrita acima. Ela lista os tempos válidos; os pares ainda dependem das posições originais.
| Tempos válidos (ms) | Média (ms) | Mediana (ms) | Mudança adjacente (ms) |
|---|---|---|---|
| 20 / 30 / 50 | 33,333 | 30 | 15 |
| 20 / 30 / 50 / 70 | 42,5 | 40 | 15 |
Reconhecer um valor indisponível
Uma resposta válida permite mínimo, máximo, média e mediana, mas não fornece um par adjacente. Duas respostas separadas por uma falha também não formam um par válido. Nesses casos, variação indisponível não significa variação medida de zero. Tempos adjacentes iguais podem dar zero: não houve mudança observada naquele par, sem comprovar uma entrega de pacotes perfeitamente constante.
Quando todas as tentativas falham, não existe resumo dos tempos. Um prazo esgotado ou endpoint indisponível não prova que toda a Internet caiu. Carga do servidor, restrições de conexão e execução do navegador também influenciam o resultado. Copiar solicita acesso à área de transferência e informa a falha quando o acesso não está disponível. Imprimir usa a janela normal do navegador; nenhuma dessas ações cria outra medição.
Investigar picos mudando uma condição
Repita primeiro nas mesmas condições e depois altere um fator. Compare o mesmo aparelho em uma conexão cabeada permitida e na posição habitual usando Wi-Fi. Anote downloads e uploads simultâneos pelos controles normais de cada aplicativo. Uma melhora repetida ajuda a escolher a próxima verificação, mas não identifica sozinha interferência, canal ocupado ou cabo danificado.
Para jogos ou chamadas, recolha também os dados de atraso e interrupção do próprio aplicativo. Protocolos e destinos distintos podem se comportar de forma diferente. Aqui não existem fases separadas de carga e repouso nem marcas de tempo de pacotes de mídia. Esta diferença HTTP não é o estimador suavizado de chegada RTP definido no RFC 3550. Falhas HTTP também não são uma porcentagem medida de perda UDP; nenhum limite certifica a qualidade de uma aplicação.
Registrar evidências para o próximo passo
Copie as amostras com o destino, horário, tipo de conexão e sintoma específico. Mantenha a indicação de incompleta em uma execução interrompida ou com falha. Descreva um padrão em várias tentativas em vez de selecionar apenas o melhor valor. Um pedido de suporte normalmente não precisa de senhas, identificadores completos da conta ou capturas com informações pessoais sem relação com o problema.
Use o teste de velocidade para a pergunta separada sobre transferência de dados. A verificação de atraso em jogos ajuda a distinguir poucos quadros por segundo, atraso de entrada e sintomas de rede. Nenhuma ferramenta transforma a sequência em diagnóstico. Um caminho HTTP tranquilo é uma observação útil; um problema persistente no aplicativo ainda exige verificações do caminho e do comportamento dele.
Como interpretar o resultado
Agendamento do navegador, reutilização de conexões, servidor e rota afetam os tempos. A variação exige pelo menos duas leituras consecutivas válidas. Erros HTTP não medem perda de pacotes IP. Os resultados não determinam jitter unidirecional, jitter RTP nem latência até um servidor de jogo ou chamada. As requisições chegam ao site e expõem os metadados usuais de conexão.
Dúvidas comuns
É igual ao comando ping?
Não. O comando ping costuma usar ICMP. Este teste cronometra requisições HTTP e inclui trabalho do navegador e do servidor.
Variação zero significa atraso zero?
Não. Tempos iguais têm mudança zero, mesmo quando cada requisição leva um tempo considerável.