Seu navegador cronometra 10 idas e voltas HTTPS reais até o Google Cloud CDN passando pelo seu Wi-Fi de verdade, seu provedor e qualquer VPN ou proxy, e mostra a mediana, a primeira conexão e o jitter.
Fareja, fareja… onde estamos?
Procurando seu IP de saída…
Quando as requisições terminarem, você vê quão rápido o Google Cloud CDN está daqui.
Para comparar, a página inicial testa o Google Cloud CDN junto com os outros serviços de Provedores de CDN: Cloudflare, Akamai, Amazon CloudFront, Fastly, Azure Front Door. O Google Cloud CDN é entregue pela rede da Google, então a ida e volta termina no data center da Google mais próximo. Gemini, Google, YouTube usam a mesma rede: se também estiverem lentos, o problema é a sua rota até a Google, não o Google Cloud CDN.
É o endereço que os sites veem quando você os acessa. Em casa, normalmente é do seu provedor de internet. Com VPN, proxy, rede do trabalho ou Retransmissão Privada do iCloud, ele pertence a quem repassa seu tráfego, que pode estar em outra cidade ou outro país. Ele também decide para qual servidor cada serviço manda você, e isso afeta a velocidade.
Porque muitos proxies e VPNs usam roteamento dividido, ou seja, escolhem o caminho conforme o site: alguns sites vão direto e o resto passa pelo proxy. Uma única verificação de IP só enxerga o próprio caminho. Por isso consultamos várias (1ms.dog, um site na China continental, Cloudflare, ip.sb, ipinfo.io, só IPv4, só IPv6, WebRTC via UDP), agrupamos por rede e marcamos cada saída como direta ou proxy. Se responderem serviços normalmente bloqueados no seu país, avisamos que há uma saída que nenhuma verificação viu.
Seu navegador abre uma conexão HTTPS de verdade com cada serviço. A primeira requisição só prepara a conexão (consulta DNS e handshakes TCP e TLS); ela aparece separada e não entra na conta. Depois, a mesma conexão é reaproveitada para algumas requisições cronometradas, e mostramos a mediana. É a ida e volta do seu aparelho até o servidor mais próximo, pelo seu Wi-Fi, provedor e qualquer proxy: o atraso que seus apps sentem de verdade.
O ping usa ICMP, que os navegadores não conseguem enviar, e muitas redes tratam ICMP de um jeito diferente do tráfego normal. Então um ping bom nem sempre significa um app rápido. A medição por HTTPS segue o mesmo caminho dos apps que você usa. Os números costumam ficar alguns milissegundos acima do ping, porque o servidor precisa responder a uma requisição.
Relâmpago ≤ 30 ms: como na mesma cidade. Disparada ≤ 80 ms: mesma região. Trote ≤ 150 ms: dá conta de quase tudo. Passeio ≤ 300 ms: dá para sentir em jogos e chamadas. Soneca > 300 ms: muito longe ou rota congestionada. Não voltou: sem conexão em 5 segundos, então o serviço não está acessível daqui. Abaixo de 2 ms aparece o lendário cão 1ms.
Seus resultados não são enviados para nós. As requisições de latência vão direto do seu navegador para os serviços medidos. Para descobrir seu IP de saída, seu navegador consulta o 1ms.dog e alguns serviços públicos de consulta de IP, que veem seu IP, porque é assim que qualquer consulta de IP funciona. Seu último resultado fica neste navegador, para mostrar o que mudou. Um resultado só sai do seu navegador se você compartilhar ou relatar um problema. Um link compartilhado leva o país e os tempos, mais cidade e rede só se você marcar a caixa, e nunca endereços IP. No 1ms.dog, o link é encurtado e uma imagem do resultado fica salva para a prévia do link nos apps de mensagem. Depois de um teste completo, seu navegador também troca algumas mensagens minúsculas com o servidor do 1ms.dog em Tóquio para medir o tempo de ida e volta até lá; esse servidor não guarda registros.
Tudo roda no seu navegador. Sem cadastro, e não coletamos seus resultados.
© 2026 1ms.dog