Por que três testes de velocidade dão três números diferentes

Três respostas, todas defensáveis

Faça um teste em três sites diferentes dentro de um minuto e você pode ver 300 Mbps, 180 Mbps e 90 Mbps. É tentador supor que dois deles estão quebrados. Na prática, cada um está respondendo a uma pergunta ligeiramente diferente, e a dispersão entre eles carrega mais informação do que qualquer número isolado.

Um está medindo quanta capacidade a linha consegue transportar quando é deliberadamente saturada. Outro está medindo a velocidade com que um download real único vai trafegar. Um terceiro pode estar medindo um caminho que nunca sai da própria rede da sua provedora. São três grandezas legítimas, com três usos legítimos.

Conexões paralelas mudam o teto

Uma única conexão TCP precisa de tempo para acelerar até a capacidade máxima da linha. Abra oito ou dezesseis ao mesmo tempo e cada uma acelera em paralelo, de modo que o agregado chega ao teto muito mais rápido — e, em um teste curto, essa diferença é grande. Por isso, testes multi-thread costumam reportar números mais altos, e são a ferramenta certa quando a pergunta é “eu recebi a capacidade pela qual paguei”.

Testes single-thread reportam números mais baixos e são a ferramenta certa quando a pergunta é “com que velocidade este download específico vai realmente acontecer”. Um stream de vídeo, o download de um jogo, um arquivo de uma CDN e uma videochamada são todos, na prática, de fluxo único. A diferença entre os dois métodos não é erro de medição; é a diferença entre um número de capacidade e um número de entrega.

A latência amplifica o efeito. Quanto maior o tempo de ida e volta, mais tempo uma única conexão passa acelerando, então enlaces de alta latência — satélite, alguns wireless fixos, caminhos internacionais longos — mostram a maior dispersão entre resultados single-thread e multi-thread.

A escolha do servidor define qual rota você mediu

Ferramentas diferentes usam redes de servidores diferentes. Algumas escolhem o endpoint disponível mais próximo, algumas usam uma rede de distribuição de conteúdo ligada a um serviço específico e outras usam servidores hospedados dentro da própria rede de uma provedora de internet. Cada escolha mede um caminho diferente.

Um teste até um servidor dentro da rede da sua provedora nunca cruza uma interconexão, então ele pode legitimamente reportar o melhor número que você já verá — e não diz nada sobre como o tráfego chega a serviços fora daquela rede. Um teste contra a CDN de um provedor de conteúdo diz como aquele provedor vai se comportar, não como a internet em geral vai se comportar. Comparar duas ferramentas que usam endpoints diferentes é comparar rotas tanto quanto conexões.

A maior fonte de erro costuma ser local

As diferenças de metodologia recebem a atenção, mas no dia a dia os maiores erros vêm do ambiente:

• Wi-Fi em vez de Ethernet. O wireless adiciona latência, jitter e variabilidade que crescem com a distância, as paredes e o número de dispositivos compartilhando a banda. Em um plano rápido, um teste cabeado e um teste sem fio no mesmo ambiente podem diferir por uma margem ampla.
• Tráfego em segundo plano. Uma sincronização na nuvem, uma atualização do sistema, um patch de jogo ou o stream em 4K de outra pessoa consome capacidade durante a janela do teste.
• Extensões do navegador e VPNs. Ambos ficam no caminho e podem limitar ou redirecionar o tráfego do teste.
• Horário do dia. Em conexões de mídia compartilhada, o mesmo teste executado às 10:00 e às 21:00 mede duas redes diferentes.

Como ler um número com contexto

Um teste de velocidade mede um caminho, até um servidor, em um momento, usando um método de transferência. Ele não prova que todo site vai carregar rápido, que um servidor de jogo vai parecer responsivo, que a rede doméstica está bem configurada ou que a capacidade vai se sustentar nos horários de pico. Trate um resultado como um retrato diagnóstico e trate o método como parte do resultado — um número sem as suas condições não é uma medição.

Também vale separar duas coisas: throughput e capacidade de resposta são independentes. Uma linha de capacidade muito alta com 200 ms de latência até a CDN mais próxima parece pior para trabalho interativo do que uma linha modesta com 10 ms. Se a reclamação é “está parecendo lento”, o número em Mbps costuma ser o dado menos útil na tela.

Uma rotina de teste repetível

Padronizar as condições importa mais do que a ferramenta escolhida.

1. Conecte-se por Ethernet sempre que possível. Se precisar usar Wi-Fi, fique no mesmo ambiente do ponto de acesso e use a banda de 5 GHz ou 6 GHz.
2. Feche tudo o que movimenta dados — backups, clientes de sincronização, atualizações, streams — no dispositivo de teste e em qualquer outra coisa que compartilhe a conexão.
3. Teste com um perfil de navegador limpo, sem extensões e sem VPN.
4. Execute três testes e adote o resultado do meio, em vez do melhor.
5. Registre o horário do dia e repita no horário mais carregado em que você normalmente usa a rede. A diferença entre os dois é o número que prevê a sua experiência real.
6. Se dois serviços discordam, teste ambos contra o mesmo servidor próximo antes de concluir que a linha é a culpada.

Faça isso uma vez no meio da manhã e uma vez à noite, e você terá um retrato mais preciso da sua conexão do que qualquer número de destaque isolado consegue dar.