Compara o ping com o link em repouso e saturado. Um aumento grande indica fila excessiva no enlace — é o que trava chamadas de voz, vídeo e jogos mesmo com banda sobrando.

Faixa e consistência da taxa instantânea durante o teste. Consistência baixa com banda alta sugere oscilação no enlace.

Cálculos sobre as medições acima — não exigem teste extra, mas traduzem os números em algo acionável num chamado com a operadora.

O navegador raramente informa o tipo de conexão: o campo existe, mas é restrito por ser vetor de impressão digital, e costuma vir preenchido só no Chrome Android. Quando não vem, inferimos pela dispersão da latência com o link ocioso: Wi-Fi carrega variação própria do meio, cabo é estável. Usamos só a fase em repouso porque congestionamento também aumenta dispersão — e o bufferbloat entra como desempate. Ressalva: Wi-Fi 6 perto do roteador pode parecer cabo, e cabo ruim ou switch congestionado pode parecer Wi-Fi.

O monitor mede requisições numa conexão já aberta. Aqui o custo é abrir uma conexão do zero — o que o usuário paga ao clicar num link enquanto alguém baixa. Cada sonda usa um endpoint que responde Connection: close, obrigando handshake novo; sem isso o navegador reaproveitaria a conexão e mediríamos zero.

Banco de dados e sessão interativa não gastam banda: gastam ida e volta. Mil consultas a 30 ms levam 30 segundos de rede, tenha o link 10 Mbps ou 1 Gbps. Aqui medimos quantos round-trips por segundo o caminho sustenta numa conexão já estabelecida.

NAT e firewall costumam encerrar conexão sem tráfego. É a causa comum de sintomas que parecem não ter relação: pool de banco devolvendo "server has gone away", sessão MSTSC caindo após inatividade e keep-alive HTTP quebrado deixando todo request mais lento. Cada intervalo é um teste independente daquele tempo de ociosidade: se 120 s falha e 60 s passou, o limite do caminho está entre os dois.

Duas medições no mesmo endpoint e protocolo, mudando só o número de conexões TCP. Uma videochamada ou um streaming usam uma conexão; um gerenciador de download ou várias abas usam muitas — os dois números respondem perguntas diferentes.

Tempos do handshake ao abrir esta página. DNS alto aponta problema no resolvedor; TCP alto aponta distância ou congestionamento.

A mediana esconde picos. Os percentis mostram o que acontece nos piores momentos — é o p95/p99 que estraga chamada de voz e jogo, não a média.

Números que o kernel do servidor mantém sobre a sua conexão. É o que separa as três causas possíveis de banda baixa: perda no caminho, limite do seu equipamento, ou nenhum dos dois.

Cada salto com a operadora (AS) a que pertence, para localizar em qual rede o problema aparece.

Várias sondas em cada salto, para localizar onde a perda começa. Atenção ao ler: perda num salto do meio com 0% nos seguintes é apenas roteador despriorizando ICMP — só conta quando persiste até o fim.

Medido por WebRTC em canal não-confiável, que se comporta como UDP puro — então a perda aqui é perda de pacote de verdade, não timeout de HTTP. UDP é o transporte de voz, vídeo e jogos: um link com banda ótima e UDP ruim dá problema que teste de velocidade comum não mostra. As duas direções são medidas separadamente.

Consomem banda de propósito, por isso ficam sob demanda. Cada uma pede uma nova verificação antes de rodar.

O HTML é um arquivo único, sem dependência externa: abre em qualquer navegador, já traz o gráfico da latência ao longo do teste e pode ser impresso em PDF. Os dados brutos vão embutidos nele, então nada se perde ao anexar num chamado.