O que é latência? Diferença para o ping e como reduzi-la

Uma videochamada em que as pessoas ficam falando umas por cima das outras, uma página que fica em branco por um instante, uma API que responde em 40 ms na maior parte do tempo e em 900 ms de vez em quando. Os três são problemas de latência, e um plano de internet mais rápido não resolve nenhum deles. Latência é o tempo de espera antes de os dados chegarem, e ela se comporta de um jeito diferente da velocidade de download que o provedor anuncia.

A seguir: o que é latência, de onde ela vem, como ela difere do ping e da largura de banda, como medi-la com ping e curl (saída real da nossa máquina de testes), quais valores são bons, como reduzi-la e o que um proxy muda.

O que é latência?#

Latência é o atraso entre o envio de dados e a chegada deles, ou entre uma requisição e a resposta. Ela é medida em milissegundos; 1.000 ms equivalem a um segundo. Quando você clica em um link, a requisição viaja até um servidor e a resposta volta, e cada trecho acrescenta espera antes que a página possa começar a aparecer.

A latência unidirecional (one-way) é só o trajeto de A até B; ela é difícil de medir, porque os relógios das duas máquinas teriam de concordar até o milissegundo. O tempo de ida e volta (RTT, round-trip time) é o trajeto de ida e de volta, cronometrado pelo próprio relógio de quem envia. A RFC 2681, a métrica de atraso de ida e volta da IETF, o define como o tempo desde o envio de um pacote de teste até a resposta chegar por completo. O ping, os testes de velocidade e a maioria das ferramentas informam o RTT, por isso, no dia a dia, "latência" significa uma ida e volta.

O que causa a latência?#

Cinco coisas se somam na latência que você mede, e a primeira define um piso que nenhuma configuração consegue remover.

1. Distância. Um sinal em fibra óptica viaja a cerca de dois terços da velocidade da luz no vácuo. A recomendação de planejamento G.114 da UIT conta 5 microssegundos por quilômetro de fibra: 5 ms a cada 1.000 km em um sentido e 10 ms na ida e volta, antes que qualquer equipamento acrescente a sua parte. Os cabos raramente seguem em linha reta, então as rotas reais são mais longas que a distância no mapa. Para um link por satélite geoestacionário, a G.114 indica cerca de 260 ms em um sentido só pelo trajeto no espaço.
2. Saltos e roteamento. Entre você e um servidor existe uma cadeia de roteadores, e cada um é um salto (hop). A rota decide quanto um pacote viaja, e o tráfego entre duas cidades próximas pode fazer um desvio por um ponto de troca de tráfego distante. O que é traceroute? mostra como listar os saltos e ver onde o tempo cresce.
3. Filas em links congestionados. Um roteador que recebe pacotes mais rápido do que consegue repassá-los os guarda em um buffer, uma fila de espera. Quando um backup na nuvem ou um upload grande enche a sua conexão, todos os outros pacotes esperam atrás dele. A latência que sobe só enquanto a linha está ocupada se chama bufferbloat.
4. Wi-Fi e rádio móvel. O Wi-Fi é um canal de rádio compartilhado: os seus aparelhos e as redes vizinhas se revezam nele, e os quadros (frames) perdidos por interferência são reenviados. Cada espera e cada nova tentativa acrescentam um atraso que muda de um momento para outro. Os dados móveis somam o próprio link de rádio até a torre de celular.
5. Tempo do servidor. O servidor precisa preparar a resposta: ler um banco de dados, montar a página, chamar outros serviços. Esse tempo é latência para você, e nada do seu lado o encurta.

Uma conexão nova com um site também custa várias idas e voltas antes de qualquer conteúdo andar: uma consulta DNS para transformar o nome em um endereço (a menos que ele esteja em cache), a conexão TCP, o handshake TLS que protege o HTTPS e, por fim, a própria requisição. Por isso, uma conexão HTTPS nova com um servidor a 100 ms de distância precisa de pelo menos três idas e voltas, cerca de 300 ms, antes de o primeiro byte chegar.

Latência versus largura de banda, taxa de transferência, jitter e perda de pacotes#

Esses termos descrevem lados diferentes de uma mesma conexão: a latência é quanto os dados esperam, a largura de banda é quanto poderia passar, a taxa de transferência (throughput) é quanto passa de fato, o jitter é quanto a latência varia e a perda de pacotes é quanto nunca chega.

Pense em uma rodovia: a largura de banda é o número de faixas, a latência é o tempo de viagem, e mais faixas não encurtam a viagem. Um ícone minúsculo e um vídeo grande esperam a mesma latência pelo primeiro byte; só o resto da transferência depende da largura de banda. O nosso guia sobre largura de banda trata do lado da capacidade.

Qual é a diferença entre ping e latência?#

Latência é o atraso em si; ping é uma ferramenta que mede um tipo dele. O comando ping envia pequenas solicitações de eco ICMP (o ICMP é o protocolo da internet para mensagens de controle e de erro) e cronometra cada resposta de eco. Os testes de velocidade pegaram o nome emprestado, então "Ping 12 ms" significa uma latência de ida e volta de 12 ms.

O ping mede o caminho de rede e pouco mais. Um navegador também espera pelo DNS, pela abertura da conexão, pelo TLS e pelo servidor, por isso uma página leva várias vezes o valor do ping. Alguns servidores ignoram totalmente as solicitações de eco e continuam servindo páginas normalmente.

Como medir a latência?#

Dois comandos que vêm com o Windows, o macOS e o Linux cobrem quase tudo: ping para a ida e volta na rede e curl para a requisição inteira, etapa por etapa. Rode os dois várias vezes contra o servidor que você realmente usa.

Meça a ida e volta com o ping#

No Windows, digite cmd na caixa Pesquisar da barra de tarefas, abra o Prompt de Comando e execute:

ping example.com

A nossa máquina de testes com Windows 11 imprimiu isto em 15 de novembro de 2026:

Pinging example.com [104.20.23.154] with 32 bytes of data:
Reply from 104.20.23.154: bytes=32 time=11ms TTL=50
Reply from 104.20.23.154: bytes=32 time=10ms TTL=50
Reply from 104.20.23.154: bytes=32 time=12ms TTL=50
Reply from 104.20.23.154: bytes=32 time=11ms TTL=50

Ping statistics for 104.20.23.154:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 10ms, Maximum = 12ms, Average = 11ms

Cada valor time= é uma ida e volta; um Windows em português escreve tempo=. O Windows envia quatro solicitações por padrão; -n 20 envia 20, e -t continua até você pressionar Ctrl+C. Os tempos são curtos porque o example.com é servido por uma rede de distribuição de conteúdo, que responde a partir de um servidor perto do visitante. No Mac ou no Linux, rode ping -c 4 example.com no Terminal; sem -c, o ping continua até você pressionar Control-C.

Veja para onde vai o tempo com o curl#

O curl busca um endereço web e, com a opção -w, informa quanto tempo cada etapa levou. Ele vem com o Windows 10 e 11, o macOS e a maioria dos sistemas Linux. No Prompt de Comando:

curl -o NUL -s -w "dns lookup:  %{time_namelookup}\nconnect:     %{time_connect}\ntls:         %{time_appconnect}\nfirst byte:  %{time_starttransfer}\ntotal:       %{time_total}\n" https://example.com

No Mac ou no Linux, escreva -o /dev/null no lugar de -o NUL e coloque o texto depois de -w entre aspas simples; no Windows PowerShell, digite curl.exe, porque lá curl é o nome de outro comando. Uma das nossas execuções imprimiu:

dns lookup:  0.005060
connect:     0.017101
tls:         0.036621
first byte:  0.056354
total:       0.056403

Os valores estão em segundos, cada um contado a partir do início da requisição, como o manual do curl os define. Subtraia cada linha da seguinte para ver uma única etapa:

• Consulta DNS (dns lookup), 5 ms. Encontrar o endereço; curta porque o nome tinha acabado de ser consultado.
• Conexão (connect), mais 12 ms. A conexão TCP, uma ida e volta, perto do valor do ping.
• TLS, mais 20 ms. O handshake que estabelece a criptografia do HTTPS.
• Primeiro byte (first byte), mais 20 ms. A requisição, o trabalho do servidor e o primeiro byte de volta.

Só os últimos 20 dos 56 ms foram para a requisição em si; o resto foi preparação da conexão.

p50 e p95: por que uma medição não basta#

A latência muda de uma requisição para outra, então um único número diz pouco. Rodamos a mesma requisição do curl 20 vezes e ordenamos os tempos de "first byte". A mediana, ou p50, foi de 70 ms: metade das requisições foi mais rápida, metade mais lenta. O p95, o valor abaixo do qual ficam 95% das requisições, foi de 91 ms, o 19º dos 20 valores ordenados. A mais lenta levou 199 ms e puxou a média para 76 ms.

Por isso as ferramentas de monitoramento e as metas de APIs usam percentis: o p50 mostra o caso típico, e o p95 e o p99, o quanto a cauda lenta fica lenta.

O que é uma boa latência?#

Não existe um número único; os poucos limites publicados valem, cada um, para um uso específico.

• Chamadas de voz e de vídeo. A ITU-T G.114 diz que, abaixo de 150 ms de atraso em um sentido, a maioria das aplicações, de voz ou não, parece essencialmente interativa, e trata 400 ms em um sentido como o limite superior para o planejamento de redes. Esse orçamento cobre a cadeia inteira, do microfone ao alto-falante, então a parte da rede precisa ser menor.
• Páginas web. A orientação do Google sobre o tempo até o primeiro byte (TTFB, time to first byte), o mesmo momento do "first byte" do curl, indica 0,8 segundo ou menos como meta aproximada para a maioria dos sites e considera ruim mais de 1,8 segundo.
• APIs e outros serviços. Não existe um padrão geral. As equipes definem a própria meta como um percentil, por exemplo "p95 abaixo de um número definido de milissegundos", e recebem um alerta quando ela não é cumprida.
• Terminais de trading, áreas de trabalho remotas e apps na nuvem. Mais baixa e mais estável é melhor; o jitter importa tanto quanto a média.

No mais, leia um ping em relação ao seu próprio histórico: se um servidor que respondia em 11 ms ontem leva 60 ms hoje, algo mudou no caminho.

Como reduzir a latência?#

A distância não pode ser vencida, mas você pode remover o atraso que você mesmo acrescenta e cortar o número de idas e voltas. Os primeiros passos não custam nada.

1. Use um cabo no aparelho que importa. Um cabo Ethernet tira do caminho o revezamento e as novas tentativas do Wi-Fi; se não der, fique mais perto do roteador.
2. Mantenha a linha livre de uploads pesados. Backups na nuvem e uploads grandes enchem a fila e aumentam a latência de todo mundo. Pause-os durante as chamadas ou ative a configuração de prioridade de tráfego que muitos roteadores chamam de QoS (qualidade de serviço).
3. Use servidores perto dos seus usuários. Uma rede de distribuição de conteúdo mantém cópias de um site perto dos visitantes, então a maioria das requisições percorre um caminho curto; o nosso guia de CDN explica como.
4. Confira o seu resolvedor DNS. Um resolvedor lento atrasa cada nome novo; se as consultas forem lentas em todos os sites, outro resolvedor pode ajudar.
5. Faça menos idas e voltas. O keep-alive do HTTP envia uma requisição após a outra por uma conexão aberta, e o HTTP/2, definido na RFC 9113, leva muitas requisições ao mesmo tempo por uma única conexão. Quando o curl buscou o example.com duas vezes pela mesma conexão, a segunda requisição pulou DNS, TCP e TLS, e o primeiro byte dela chegou depois de 21 ms em vez de 71 ms.
6. Dê provas ao seu provedor. Se a latência continuar alta no cabo, com nada mais rodando, mande os resultados de ping e traceroute ao suporte.

Como um proxy afeta a latência?#

Um proxy acrescenta uma parada: a sua requisição vai ao servidor proxy, que abre a conexão com o site e repassa a resposta. Quanto isso custa depende principalmente de onde fica a saída e de como você usa a conexão.

• Escolha uma saída no caminho, não um desvio. Cada requisição viaja de você até o proxy, daí até o site e volta. Uma saída no país ou na cidade do site mantém curto o último trecho; uma em um terceiro continente acrescenta dois trechos longos a cada ida e volta.
• Reaproveite conexões. Cada conexão HTTPS nova por um proxy repete a preparação: a conexão com o proxy, o túnel até o site e o handshake TLS. O keep-alive e o HTTP/2 pagam esse custo uma vez só, e uma sessão fixa mantém a mesma saída pelo tempo que você escolher, de 1 a 60 minutos.
• Espere mais variação em linhas residenciais e móveis. As saídas residenciais e móveis ficam em conexões reais de consumidores, então a latência delas varia mais que a das saídas em data centers.

Para medir, rode o comando do curl pelo proxy com -x e compare com uma execução direta:

curl -x http://user:pass@pr.proxynet.io:8000 -o NUL -s -w "connect: %{time_connect}  tls: %{time_appconnect}  first byte: %{time_starttransfer}\n" https://example.com

Por um proxy, "connect" é a conexão com o próprio proxy, "tls" inclui também a abertura do túnel do proxy até o site, e a consulta DNS cai quase a zero porque quem resolve o nome é o proxy; verificamos isso com um proxy de teste local. Os números reais dependem da saída que você escolher, então compare as medianas de 20 execuções.

Os Proxies residenciais deixam você escolher o país e a cidade de saída, e assim você pode colocar a saída perto do site com que trabalha.

Para tempos estáveis a partir de endereços fixos, como verificar uma API de um mesmo local a cada poucos minutos, os Proxies de datacenter mantêm as saídas em redes de servidores.

Onde a latência importa#

• Páginas web e lojas online: cada conexão nova e cada arquivo que bloqueia o carregamento acrescentam idas e voltas antes de a página aparecer.
• Chamadas de vídeo e telefonia pela internet: o atraso faz as pessoas falarem umas por cima das outras; o jitter deixa o áudio picotado.
• APIs: um clique pode disparar uma cadeia de chamadas, e as latências delas se somam.
• Terminais de trading: o tempo entre uma mudança de preço e a chegada da ordem à bolsa.
• Áreas de trabalho remotas e apps na nuvem: cada tecla pressionada faz uma ida e volta.
• Web scraping e monitoramento: milhares de requisições multiplicam cada ida e volta.

Erros comuns#

• Contratar um plano mais rápido para resolver atraso. Mais Mbps raramente muda a latência; a causa costuma ser o Wi-Fi, uma linha ocupada ou a distância.
• Julgar por um único ping. Rode 20 ou mais e compare a mediana com os valores mais lentos.
• Testar contra o servidor errado. Um teste de velocidade escolhe um servidor perto de você; o site que você usa pode estar longe.
• Ler um ping sem resposta como queda. Alguns servidores ignoram as solicitações de eco e continuam servindo páginas.

Guia de decisão#

Perguntas frequentes#

Qual é uma boa latência de internet?#

Depende do uso. Para chamadas, a ITU-T G.114 diz que a maioria das aplicações parece essencialmente interativa abaixo de 150 ms em um sentido, de ponta a ponta, então um ping bem abaixo disso deixa margem para os aparelhos. Para páginas web, o Google sugere um tempo até o primeiro byte de 0,8 segundo ou menos. Acima de tudo, compare com a sua própria referência.

O que significa baixa latência?#

Baixa latência significa que os dados chegam com pouca espera, e as respostas parecem imediatas. O que conta como baixo depende da tarefa e da distância, e uma conexão só merece o nome quando o atraso é curto e estável.

Mais largura de banda reduz a latência?#

Geralmente não. A largura de banda decide quantos dados passam por segundo; a latência vem da distância, do roteamento, das filas e do servidor. A exceção é uma linha que vive cheia: nela, capacidade extra encurta as filas.

O que são latência ociosa, de download e de upload em um teste de velocidade?#

A latência ociosa (idle) é medida antes do teste, com a linha tranquila. As latências de download e de upload são medidas enquanto o teste enche a linha em cada sentido. Uma grande diferença entre o valor ocioso e os valores com carga aponta para bufferbloat.

Por que a minha latência é maior no Wi-Fi do que no cabo?#

O Wi-Fi é um canal de rádio compartilhado: os aparelhos se revezam e reenviam quadros perdidos por interferência, o que acrescenta atraso e o faz variar. Distância, paredes e redes vizinhas congestionadas pioram a situação; um cabo tira essa parte do caminho.

Um proxy ou uma VPN aumentam a latência?#

Geralmente um pouco, porque o tráfego faz uma parada extra. O aumento fica pequeno quando a saída está perto do destino e cresce com um desvio; rode o mesmo comando do curl com e sem o proxy ou a VPN para ver a diferença.

Em resumo#

Latência é o tempo que os dados esperam pelo caminho, geralmente informado como uma ida e volta em milissegundos. Distância, roteamento, filas, Wi-Fi e o servidor a causam, e largura de banda não a cura. Meça com ping e curl -w, leia a mediana e o p95 em vez de um valor só e reduza com um cabo, servidores próximos e menos idas e voltas. Quando as suas requisições precisarem sair de um país ou de uma cidade específicos, compare as opções de saída na nossa página de produtos de proxy.