Como medimos

As ferramentas do StackNest são sondas de navegador, não instrumentos de laboratório. Usam as mesmas APIs que qualquer página web tem: fetch, performance.now(), RTCPeerConnection e algumas propriedades do navigator. Isso basta para responder "tem algo errado aqui?" em poucos segundos, e não basta para substituir uma bancada com cabo, a medição da sua operadora ou o próprio cliente do jogo.

Nada é instalado e não há cadastro. A lógica de medição roda no seu dispositivo — nosso servidor não calcula sua latência, sua velocidade nem seu perfil de hardware por você.

Cada alvo é sondado três vezes por HTTP, cronometrado com performance.now() desde imediatamente antes da requisição até a resposta chegar. Informamos a mediana das amostras bem-sucedidas, e não a média, para que um engasgo isolado não domine uma série de três. Toda requisição leva um cache-buster e vai com no-store, então nada é respondido do cache, e qualquer tentativa ainda aberta após 8 segundos é abortada.

Os alvos são recursos públicos estáveis: uma imagem de campeão no CDN de League of Legends, favicons em domínios oficiais das publicadoras, uma imagem do CDN da Steam, uma borda da Cloudflare. Eles aproximam o caminho até uma região, não o servidor da partida. Em português os alvos sul-americanos são sondados primeiro; em inglês, América do Norte e Europa.

Este número não é o seu ping dentro do jogo, e normalmente é maior. Uma ida e volta HTTP inclui resolução DNS, handshakes TCP e TLS e a resposta de um servidor web, enquanto o cliente do jogo manda pacotes UDP por uma sessão que já mantém com o servidor da partida. Use nosso resultado para comparar regiões e detectar rota ruim — use o placar do próprio jogo para o número que decide a sua partida.

O teste de velocidade usa os endpoints públicos da Cloudflare. A latência são oito requisições de zero byte; o download são três transferências de 250 KB, 1 MB e 2,5 MB; o upload são três de 200 KB, 750 KB e 1,5 MB. A taxa de cada transferência é bytes × 8 ÷ segundos decorridos, e o valor exibido é a mediana das transferências que concluíram. O que ainda estiver rodando após 25 segundos é abandonado em vez de reportado.

Essas cargas são propositalmente leves — o suficiente para ser honesto num celular com franquia de dados, insuficiente para saturar um link rápido. Em conexões de 1 Gb o resultado sai baixo, porque um arquivo de 2,5 MB termina antes de a conexão atingir a velocidade máxima. Para discutir com a operadora, use um teste multi-servidor que satura o link; para saber se tem algo errado agora, este é mais rápido e gasta muito menos dados.

O jitter é a média das diferenças absolutas entre amostras consecutivas de latência — quanto a ida e volta variou de uma requisição para a seguinte. Precisa de pelo menos duas amostras bem-sucedidas. Trate como sinal de estabilidade, não como a variação de atraso de pacote (PDV) da ITU-T que um engenheiro de redes citaria.

O teste de vazamento abre uma RTCPeerConnection contra servidores STUN públicos, coleta os endereços que o WebRTC revela numa janela de três segundos e compara com o IP público que a página enxerga. O WebRTC expor um endereço local (192.168.x.x e semelhantes) é esperado e inofensivo; expor um endereço público diferente do da sua VPN é o caso que merece atenção.

No DNS, lemos qual resolvedor respondeu por você, com IP e localização aproximada. Um IP de resolvedor diferente do seu IP público é normal — a maioria das pessoas usa o resolvedor recursivo da própria operadora —, então reportamos isso como observação, não como veredito.

Não cravamos "você está vazando" a partir de sinais de navegador. Quando a evidência não resolve a questão, o resultado diz inconclusivo e mostra o que foi observado. Um teste conclusivo de vazamento exige sondas de fora do seu navegador, e afirmar uma certeza que não temos seria pior do que dizer que não sabemos.

Os números de hardware são o que o navegador decide expor, e os navegadores os embaçam de propósito para dificultar fingerprinting. navigator.hardwareConcurrency informa núcleos lógicos, mas modos de privacidade costumam fixar o valor em 2, independentemente do processador real.

A memória é ainda mais embaçada: navigator.deviceMemory existe só no Chromium e é arredondada para uma faixa entre 0,25 e 8 GB. Um Mac de 16 GB reporta 8 GB no melhor caso, e Safari e Firefox não reportam nada. Quando o valor não vem, dizemos que o navegador não expõe — nunca estimamos RAM a partir de outros sinais.

Quando vemos dois núcleos junto de memória ausente ou muito baixa, marcamos como provável proteção de privacidade, e não como máquina fraca. Com a bateria é igual: se navigator.getBattery não existe, a ferramenta diz isso em vez de chutar uma porcentagem.

Cores e rótulos vêm de limiares fixos, então o mesmo resultado é sempre lido da mesma forma:

Ping — bom / médio / alto

< 55 ms · 55–95 ms · ≥ 95 ms

Latência do teste de velocidade

< 40 ms · 40–90 ms · ≥ 90 ms

Jitter — estável / moderado / instável

< 8 ms · 8–25 ms · ≥ 25 ms

Download

< 5 · 5–25 · 25–100 · 100–300 · ≥ 300 Mbps

São faixas voltadas ao consumidor, escolhidas por legibilidade — não são normas. Um ping de 60 ms é tranquilo num jogo de estratégia e sofrido num FPS; 20 Mbps sobra para uma transmissão e aperta numa casa com quatro pessoas.

Feche outras abas e downloads, prefira cabo ou fique perto do roteador, e repita o teste em horários diferentes — uma amostra isolada diz pouco sobre uma conexão que só piora à noite. Modo de economia de bateria e sincronização em segundo plano também deixam o navegador lento o bastante para aparecer nos números.

Se o nosso resultado divergir de uma ferramenta especializada, confie na especializada: o cliente do jogo para a latência da partida, um teste multi-servidor que satura o link para a taxa, e uma sonda fora do navegador para vazamento conclusivo. Estas ferramentas existem para dizer rápido se algo merece esse exame mais profundo.