Teste de Velocidade da Internet

O que cada número quer dizer

O que é um ping bom em cada uso, de onde vem a latência e como reduzir o jitter estão no guia ping, jitter e latência.

Como a medição funciona

O teste começa pedindo uma sessão ao servidor, que responde com o datacenter da Cloudflare que vai medir, a operadora pelo número do sistema autônomo (AS) e um passe temporário, que vale por dez minutos e só serve para as medições deste teste. Depois vêm 20 medidas de latência com a conexão parada (12 no modo econômico). A primeira aquece a conexão e sai da conta, e a latência é a mediana das outras. Cada medida é o tempo entre o pedido sair e o primeiro byte da resposta chegar, registrado pelo próprio navegador (a especificação Resource Timing, do W3C), no endereço de diagnóstico que a borda da Cloudflare responde sozinha, sem passar pelo servidor de teste: assim o tempo de processamento do servidor não entra na latência.

O download abre 4 conexões WebSocket em paralelo, cada uma sobre um TCP próprio, e soma os bytes de todas em caixas de 100 milissegundos. O servidor manda os dados em mensagens, e o navegador confirma o que já recebeu: cada conexão pode ter mandado e ainda não confirmado o equivalente a 250 ms da própria vazão (ou 3 voltas, se a latência for alta), entre 0,5 e 4,2 MB. Essa janela protege a memória do servidor sem frear a transferência, e no fim da fase deixa pouco dado na fila: o navegador avisa o fim e espera o servidor fechar. Se dobrar o número de conexões aumenta a velocidade em pelo menos 3%, o teste tenta dobrar de novo, até 16 conexões no modo completo. Numa linha com perda de pacotes cada conexão fica presa a poucos Mbps, e é ali que mais conexões rendem. Se a velocidade fica igual, as conexões novas ficam: desfazer a dobra não sai de graça, porque as conexões que sobram estão ajustadas para a parte da linha que dividiam e levam segundos para encher de novo. O teste só volta ao número anterior quando a velocidade cai mais de 4% e fica lá em dois trechos seguidos de pelo menos 1 segundo, porque em algumas operadoras conexão a mais rende menos. Se ela ainda está caindo ou subindo, é a transição da dobra, e as conexões ficam; numa linha em que a velocidade nunca firma um patamar, como a que perde pacotes, também ficam, porque ali ela sobe e desce sozinha e a comparação não diz nada. E, se a latência medida durante a transferência já subiu 5 ms ou um quarto da latência parada (o que for maior), a linha está cheia e o teste nem tenta dobrar. Antes da primeira dobra, ele espera essas medidas (até 4 segundos de fase), em vez de dobrar sem saber se a fila já se formou. Abaixo de 2 Mbps também não: cada conexão ficaria com tão poucos pacotes a caminho que uma perda viraria espera. Também não tenta quando a fase não tem mais tempo ou dados para abrir as conexões novas, testar a dobra e ainda medir 3 segundos depois dela, o que acontece nas conexões mais rápidas, que chegam antes ao teto de dados, e nas de latência alta, em que abrir uma conexão leva três voltas. O motor roda num Web Worker, uma linha de execução separada da página, para a leitura dos dados não disputar o processador com a tela.

Por que WebSocket, e não os pedidos comuns do navegador? Com a Cloudflare, a maioria dos navegadores usa o HTTP/3, que roda sobre o protocolo QUIC. Na linha em que o método foi ajustado, o download pelo HTTP/3 oscilava até 40% de um décimo de segundo para outro e ficava de 5% a 7% abaixo do mesmo download por TCP, e o upload chegava ao servidor aos trancos. O WebSocket abre uma conexão TCP nova para cada fluxo. Se a rede bloquear WebSocket, o que acontece em algumas redes de empresa, o teste mede pelos pedidos comuns do navegador, com pedidos de cerca de 1 segundo na velocidade medida até ali e no máximo 12 conexões no download e 8 no upload, porque cada pedido conta no limite por minuto do servidor.

O começo de cada fase é a rampa, quando a conexão ainda está acelerando. Ela não tem tamanho fixo: acaba quando a média de uma janela de 300 ms (ou duas vezes o tempo de ida e volta, se ele for maior) muda menos de 5% em relação à janela anterior e já passou de 90% do maior patamar visto. Numa conexão com latência alta a rampa demora mais, e o motor espera por ela. No fim da fase, esse ponto é conferido contra o nível que a conexão sustentou, a média da segunda metade. Numa linha que oscila, as duas médias podem só concordar por acaso, quase no fim, e a janela ficaria com dois segundos em vez de dez; depois de uma queda, elas concordam no patamar baixo, antes de a vazão voltar. Nesses casos, a janela começa quando duas médias seguidas passam de 90% do nível sustentado. Uma média acima de 1,5 vez o nível por menos de 0,5 segundo não conta: é a rajada dos dados que esperavam uma retransmissão, e começar nela contaria de novo o que chegou antes da janela. Numa linha abaixo de 50 Mbps, a janela do download também não começa antes de 1,5 segundo depois da abertura da última conexão: enquanto uma conexão abre, o navegador segura a entrega das outras por alguns décimos de segundo e depois solta tudo de uma vez, e começar ali contaria dentro da janela o que passou pela linha antes dela. Numa linha de 10 Mbps, isso punha o resultado de 0,6% a 2,4% acima do que a linha entregou. Nas linhas mais rápidas, a espera não mudou o erro no laboratório e só alongava o teste.

Depois da rampa, o resultado é a média das caixas. O teste para quando essa média fica firme: as caixas são agrupadas em lotes de pelo menos 1 segundo, e, com 3 lotes ou mais, o intervalo de confiança de 95% da média (distribuição t de Student) precisa caber em ±2% (4% no econômico), depois de pelo menos 3 segundos medidos e nunca antes de 6 segundos de fase (4 no econômico). Se não firmar, a fase para em 12 segundos (7 no econômico) ou no teto de dados, e a tela mostra a margem de erro que sobrou.

Algumas operadoras liberam um reforço no começo de cada transferência: a conexão corre bem acima do plano por um ou dois segundos e depois cai para a velocidade que sustenta. Na linha em que o método foi ajustado, o upload chegava a 480 Mbps por 2 segundos e depois ficava em 255 Mbps até o fim. Para achar isso, o motor resume as caixas em lotes de 500 ms e procura o ponto em que a média muda de vez, com diferença de pelo menos 20% e firme o bastante para não ser ruído (estatística t de pelo menos 5), com pelo menos 2 segundos depois da mudança. Só vale como reforço a primeira mudança, e só quando ela é uma queda, acontece na primeira parte da fase (até 60% do trecho medido) e tem forma de degrau: a distância entre as medianas dos dois trechos precisa passar de 3 vezes a oscilação típica das caixas, e o patamar de baixo precisa ser plano, sem a subida lenta de quem está se recuperando de uma queda. Numa linha com perda de pacotes a velocidade sobe e desce sozinha, e, sem essa exigência, 6% das medições simuladas ganhavam um reforço que não existia. O número publicado é a média depois do reforço, porque é ela que a conexão entrega numa transferência longa, e o reforço aparece à parte no resultado, com a velocidade e a duração. É também por isso que a fase não para antes de 6 segundos: um reforço de 3 segundos pareceria um patamar firme. E a janela nunca começa antes de o reforço acabar, mesmo quando o teste muda o número de conexões no meio dele.

No upload, o navegador gera uma vez um bloco de bytes aleatórios, que não se comprimem, e manda por até 16 conexões WebSocket. A cada 100 ms o servidor avisa quantos bytes já chegaram, pelo relógio dele, e o número publicado sai desses avisos, e não do que saiu do aparelho, que ainda pode estar parado numa fila do caminho. Quando o download ficou abaixo de 5 Mbps, o upload começa com 2 conexões, e não 4: numa linha lenta, cada conexão a mais divide uma fila curta, perde pacote o tempo todo, e o servidor passa segundos esperando a retransmissão antes de contar o que já tinha chegado. E o envio só começa quando as conexões do começo abrem, no máximo 2 segundos depois: enviando pela primeira que abre, o aperto de mão das outras ficava na fila atrás desse dado. Em cada conexão o navegador mantém uma fila curta, de cerca de 200 ms de dados: o bastante para o TCP nunca ficar sem o que mandar, e pouco para o fim da fase não demorar a esvaziar. Antes do primeiro aviso do servidor, essa fila começa pela velocidade do download que acabou de ser medida: com uma fila de partida fixa e grande, numa linha de 1 Mbps a fase inteira era a fila inicial. As mensagens têm cerca de 20 ms de dados, com no mínimo 4 kB: o servidor só conta a mensagem que chegou inteira, e numa linha lenta mensagem grande deixa a borda da conta imprecisa. A janela do upload termina no instante em que a fase parou, levado para o relógio do servidor. Depois dele, o que ainda está na fila do navegador não entra no resultado: abaixo de 50 Mbps, as conexões fecham assim que o servidor avisa que contou até esse instante, em vez de esperar a fila esvaziar, o que a 1 Mbps levava até 4 segundos. A janela recomeça depois da última mudança no número de conexões, como no download. Abaixo de 50 Mbps, depois de uma mudança a janela ainda espera 1,5 segundo desde a abertura da última conexão nova: no começo, as conexões novas perdem pacotes, o servidor segura o que chegou depois de cada pacote perdido até a retransmissão e então conta tudo de uma vez. Numa linha de 5 Mbps, começar antes punha o upload até 2,5% acima do que a linha entregou. Quando o upload precisa ir pelos pedidos comuns, o servidor devolve a linha do tempo de cada envio, e um envio interrompido no fim da fase faz a conta parar antes dele, para não contar tempo sem os bytes correspondentes.

Durante o download e o upload, outras medidas de latência correm a cada 300 ms (400 ms no econômico), numa conexão diferente da que está transferindo, como faria uma chamada de vídeo aberta ao lado de um download. O aumento da mediana com a rede cheia em relação à latência parada vira a nota do bufferbloat: A+ abaixo de 5 ms, A abaixo de 30 ms, B abaixo de 60 ms, C abaixo de 200 ms, D abaixo de 400 ms e F a partir de 400 ms. O A+ vem do CoDel, algoritmo de gestão de fila descrito na RFC 8289, que mira 5 ms de fila; a partir de C, quem joga ou está em chamada já sente o aumento.

O teste também se vigia. Se a aba ficar escondida, se o aparelho atrasar a leitura em mais de 40 ms (processador ocupado), se a rede trocar no meio, se outros conteúdos da página usarem mais de 2% dos dados da fase ou se algo no caminho comprimir os bytes, o resultado sai com um aviso e o convite para medir de novo. Com VPN, iCloud Private Relay ou Cloudflare WARP ligados, a tela avisa que a medida é do serviço, e não da operadora.

O teto de dados conta tudo o que já foi pedido ao servidor, e não só o que chegou: no modo completo são 1.000 MB de download e 500 MB de upload, no máximo; no econômico, 160 MB e 90 MB. Numa conexão de 100 Mbps, o teste para bem antes disso, porque a média firma em poucos segundos. Quem quiser os números crus de cada medição pode abrir o painel Como chegamos nesses números depois do teste.

Por que o resultado fica abaixo do plano

• O Wi-Fi é a perda mais comum. A faixa de 2,4 GHz alcança mais longe, mas sofre interferência de outros aparelhos que usam a mesma faixa; a de 5 GHz é mais rápida e perde força com paredes e distância.
• Uma porta de rede de 100 Mbps (Fast Ethernet) nunca passa de 100 Mbps, mesmo num plano de 500. Acima disso, placa de rede, cabo e roteador precisam ser gigabit.
• TV em streaming, backup do celular e atualização do console dividem a mesma banda enquanto você mede.
• À noite a rede da operadora fica mais cheia. Celular antigo ou computador com o processador ocupado também não dão conta de receber tudo.
• Com VPN, todo o tráfego passa pelo servidor dela, que pode estar longe ou lotado.

Para saber o que a operadora entrega, feche os outros programas, ligue o computador no roteador por cabo e repita o teste em dias e horários diferentes.

A regra da Anatel sobre velocidade contratada

A regra dos 40% e 80% vinha do Regulamento de Gestão da Qualidade da banda larga fixa (RGQ-SCM, Resolução 574/2011): pelo menos 40% da velocidade máxima contratada em 95% das medições instantâneas do horário de maior tráfego, e 80% na média do mês. A Resolução 717/2019, que aprovou o Regulamento de Qualidade dos Serviços de Telecomunicações (RQUAL), revogou esse regulamento, os dois percentuais saíram junto, e a coleta dos indicadores antigos terminou com os resultados de fevereiro de 2022.

Hoje, segundo a página de direitos do consumidor da Anatel, a prestadora tem de informar antes da contratação as velocidades mínima e média de conexão, e o consumidor deve receber a velocidade acordada em contrato. É por isso que a comparação desta página não usa percentual fixo: ela compara o teste com a mínima e a média que você digita, lidas da sua oferta ou do seu contrato. O Regulamento Geral de Direitos do Consumidor (Resolução 765/2023), em vigor desde 1º de setembro de 2025, proíbe a multa de fidelidade quando a prestadora descumpre o contrato (artigo 37). O mesmo artigo conta como descumprimento a operadora cair para o selo D ou E do RQUAL no seu município depois da contratação, e diz que, na banda larga fixa, o consumidor pode comprovar o descumprimento conforme o Manual Operacional do RQUAL.

O RQUAL não olha percentual do plano. Os indicadores de rede contam quantas medições alcançam valores de corte fixos. Na banda larga fixa, a Resolução Interna 444/2025 usa dois cortes de velocidade (5 Mbps de download com 1 Mbps de upload, e 25 Mbps com 5 Mbps), 80 ms de latência, 40 ms de jitter e 2% de perda de pacotes. Na banda larga móvel, os cortes de latência e de jitter são 100 ms e 25 ms. Esses números avaliam a rede da operadora em cada município, e não o contrato de uma pessoa, mas servem de régua para ler o seu resultado. As medições oficiais são as da ESAQ, no site Brasil Banda Larga e no aplicativo ESAQ. O guia Banda larga e as regras da Anatel explica onde achar a mínima e a média na oferta e como reclamar.

Como reclamar da velocidade

1. Meça no cabo, em dias e horários diferentes, aqui e no Brasil Banda Larga. Guarde os resultados.
2. Fale com a operadora e anote o número de protocolo.
3. Sem solução, procure a ouvidoria da operadora e anote o novo protocolo.
4. Registre a reclamação na Anatel pelo telefone 1331 (grátis, dias úteis, das 8h às 20h), pelo site ou aplicativo Anatel Consumidor ou pelo WhatsApp da agência (0800 61 0 1331), que só atende quem já tem cadastro no Anatel Consumidor. A operadora tem dez dias corridos para responder.

O que acontece com os dados do teste

O que vai para o servidor do portal são bytes aleatórios gerados na hora pelo navegador; o servidor conta quantos chegaram e os descarta. A velocidade do plano e os percentuais do contrato que você digita ficam no navegador. A borda da Cloudflare, que entrega o site inteiro, enxerga o endereço de quem faz o teste, como enxerga qualquer visita, e é daí que vêm o IP, a operadora e o datacenter do painel. O nome reverso sai de uma consulta ao DNS público da própria Cloudflare, feita pelo servidor de teste só com o seu próprio endereço; se ela não responder, o campo fica de fora, sem consultar mais ninguém. Nada disso é gravado no servidor. Os resultados ficam só neste navegador, na lista Seus testes neste aparelho, sem o IP, e o botão Apagar histórico limpa tudo. Para saber o que mais o seu endereço revela, use o Meu IP. Antes de uma chamada importante, vale também passar pelo teste de microfone e pelo teste de webcam.