Comece pelo destino, não por uma nota universal
Em jogos rápidos, interessa um tempo de ida e volta baixo e estável até o servidor do jogo. As faixas são referências editoriais para comparação, não um padrão oficial ou garantia.
| Tempo de ida e volta | Interpretação de referência |
|---|---|
| Abaixo de 50 ms | Um objetivo de baixa demora para interação rápida. |
| 50–100 ms | Pode ser jogável; confira o jogo e a estabilidade. |
| 100–150 ms | O atraso pode ficar mais perceptível em jogos rápidos. |
| Acima de 150 ms | Costuma responder pior, mas não comprova defeito. |
Não aplique a tabela como exigência universal para chamadas ou streaming. Chamadas também dependem de jitter, perdas e buffers; vídeo previamente armazenado depende bastante de vazão e estabilidade. Uma medição no navegador não certifica a experiência.
Ping, latência e estabilidade
O comando ping convencional usa eco ICMP. RTT inclui ida e volta; dividi-lo por dois não determina com segurança a demora em um sentido, pois rotas e filas podem ser diferentes. Mbps representa capacidade, não o mesmo que demora em ms.
A variação costuma ser chamada de jitter; perda de pacotes é outra métrica. Registre destino e método, porque ferramentas podem calcular estatísticas distintas.
O que o IPdidi mede
O teste de ping faz 2 solicitações de aquecimento e 40 medições HTTP em /ping.txt, no ponto Cloudflare que atende o site. Não envia ICMP nem mede o servidor do jogo.
Normalmente usa de requestStart a responseStart, intervalo HTTP que pode incluir processamento do servidor. Sem esse dado, usa o tempo decorrido de fetch, incluindo a leitura da resposta. Não garante RTT puramente de rede.
O jitter exibido é a média da diferença absoluta entre amostras adjacentes bem-sucedidas. Timeout ou erro HTTP é amostra que falhou, não uma taxa de perda de pacotes IP. As notas por uso são heurísticas do site. A descrição vem da inspeção do código, não de um teste na sua conexão ou aparelho.
Faça comparações equivalentes
- Anote destino, ferramenta, horário, Wi-Fi ou cabo, VPN, média, variação e falhas.
- Repita em repouso e durante download ou upload normal, com o mesmo destino e método.
- Compare Ethernet e Wi-Fi se puder. Isso ajuda a separar fatores sem fio, sem garantir um número menor.
- Confira o diagnóstico do jogo ou do aplicativo de chamadas. Um resultado bom para um ponto não exclui problemas locais, de rota, servidor ou aplicativo em outro contexto.
Para comparar ICMP, execute ping example.com no terminal e pare com Ctrl+C se continuar. O destino pode filtrar eco; não responder não prova indisponibilidade do serviço.
Altere um item e teste de novo
- Pause transferências grandes e backups para verificar filas sob carga.
- No Wi-Fi, compare posição e bandas ou canais menos ocupados; 5 GHz não é automaticamente melhor atrás de paredes ou longe do roteador.
- Compare uma região adequada do jogo e VPN ligada/desligada na mesma atividade. VPN e plano mais rápido não garantem menor latência.
- Se houver gerenciamento de filas, siga o manual oficial do roteador. Ele pode ajudar nas filas, mas não eliminar a distância de propagação.
- Se persistir, forneça ao suporte destino, horários e resultados em repouso e sob carga, não apenas o mínimo.
Use o mesmo teste antes e depois. Não atribua a causa apenas à diferença entre dois destinos.
Dúvidas comuns
100 ms é sempre ruim?
Depende da tarefa, destino, protocolo e estabilidade. É um valor para investigar, não uma nota universal.
Falha HTTP significa perda de pacotes?
Não. Há várias causas e este teste não determina a taxa de perda da rede.
Por que o jogo mostra outro número?
Destino, tráfego e processamento mudam. Compare os diagnósticos do próprio aplicativo, sem subtrair medições sem relação.
Fontes e escopo
Este guia explica métricas e um processo de comparação. Não afirma identificar uma falha na sua conexão nem testar um aparelho específico.
Fontes verificadas: 2026-11-05.