Latência é o atraso de tempo entre o envio de uma requisição e o recebimento de uma resposta. É medida em milissegundos e afeta cada interação do usuário na internet.
Resumo Latência é o tempo que os dados levam para viajar de um remetente a um receptor e de volta, medido em milissegundos (ms). Em redes, a latência é frequentemente expressa como RTT (Round-Trip Time / Tempo de ida e volta). A latência típica de banda larga é de 10–50 ms para servidores próximos e de 100–300 ms para servidores em outros continentes. Latência acima de 100 ms é perceptível para usuários em aplicações interativas. Latência acima de 300 ms é considerada ruim. As quatro causas principais de latência são: atraso de propagação (distância física), atraso de transmissão (largura de banda), atraso de processamento (hardware/software) e atraso de filas (congestionamento). O edge computing reduz a latência processando requisições mais próximas dos usuários em vez de roteá-las para centros de dados centralizados.
O que é latência?
Latência é o tempo decorrido entre o envio de uma requisição e o recebimento de uma resposta. Em redes, é mais comumente medida como RTT (Round-Trip Time) — o tempo para um pacote viajar do cliente ao servidor e de volta.
A latência é medida em milissegundos (ms). Menor latência significa respostas mais rápidas.
Latência não é o mesmo que largura de banda. Largura de banda é quanto dado pode ser transferido por segundo. Latência é o atraso antes que essa transferência comece. Uma conexão de alta largura de banda ainda pode ter alta latência.
Os 4 componentes da latência de rede
A latência de rede é a soma de quatro atrasos distintos:
| Componente | Definição | Controlável? |
|---|---|---|
| Atraso de propagação | Tempo para um sinal viajar a distância física entre remetente e receptor. A luz viaja pela fibra a ~200.000 km/s. | Não — limitado pela física |
| Atraso de transmissão | Tempo para enviar todos os bits do pacote ao cabo, dependente da largura de banda do link. | Parcialmente — melhorar a largura de banda |
| Atraso de processamento | Tempo para roteadores, switches e servidores inspecionarem e processarem os cabeçalhos dos pacotes. | Sim — otimização de hardware e software |
| Atraso de filas | Tempo que os pacotes aguardam em buffers sob congestionamento de rede. | Sim — gestão de tráfego, planejamento de capacidade |
O atraso de filas é o componente mais variável — pode disparar de quase zero a centenas de milissegundos sob congestionamento.
Valores típicos de latência por cenário
| Cenário | Latência típica |
|---|---|
| Mesmo datacenter (rede local) | < 1 ms |
| Cidade a cidade, mesmo país | 5–20 ms |
| Transcontinental (ex.: EUA Leste a EUA Oeste) | 60–80 ms |
| Transatlântico (EUA a Europa) | 80–120 ms |
| Transpacífico (EUA a Ásia) | 150–300 ms |
| Rede móvel 4G | 30–100 ms |
| Rede móvel 5G | 1–10 ms |
| Internet via satélite (LEO, ex.: Starlink) | 20–60 ms |
| Internet via satélite (GEO) | 500–700 ms |
| LAN com fio (Ethernet) | < 1 ms |
Um servidor em São Paulo entrega respostas em ~15 ms para usuários em São Paulo e em ~170 ms para usuários em Tóquio — não pela velocidade do servidor, mas pela distância física.
Latência vs largura de banda
| Latência | Largura de banda | |
|---|---|---|
| Definição | Atraso antes que a transferência de dados comece | Throughput máximo de dados por segundo |
| Medida em | Milissegundos (ms) | Megabits por segundo (Mbps) ou Gbps |
| Analogia | Quanto tempo antes do primeiro caminhão partir | Quantos caminhões podem viajar por hora |
| Afetada por | Distância, roteamento, congestionamento, processamento | Capacidade do link, hardware, protocolo |
| Melhora com | Edge computing, roteamento otimizado, cache | Atualizar os links de rede |
Alta largura de banda não resolve alta latência. Uma conexão de 10 Gbps com 300 ms de latência ainda parecerá lenta para aplicações interativas.
Impacto da latência por tipo de aplicação
| Aplicação | Latência aceitável | Limite de latência ruim | Por que importa |
|---|---|---|---|
| Carregamento de página web (TTFB) | < 200 ms | > 500 ms | Google: 53% dos usuários móveis abandonam páginas que levam mais de 3 segundos |
| Chamadas a APIs | < 50 ms | > 200 ms | A 1.000 chamadas/seg, 1 ms extra de latência = 1 s de sobrecarga adicionada |
| Streaming de vídeo | < 150 ms | > 500 ms | Causa buffering e interrupções de reprodução |
| Jogos online | < 50 ms | > 100 ms | “Lag” perceptível que afeta o gameplay |
| VoIP / videochamadas | < 150 ms | > 300 ms | Causa ecos, interrupções mútuas, má qualidade de chamada |
| Trading de alta frequência | < 1 ms | > 5 ms | Diferenças de microssegundos determinam lucros e perdas |
| Inferência de IA em tempo real | < 100 ms | > 500 ms | Determina se interfaces com IA parecem responsivas |
Como reduzir a latência
As estratégias mais eficazes para reduzir a latência, ordenadas por impacto:
- Aproximar o processamento dos usuários — Processar requisições em servidores próximos ao usuário elimina viagens transatlânticas. Um usuário em São Paulo atendido por um nó distribuído próximo obtém entre 5 e 15 ms de latência em vez de 150 ms de uma origem nos EUA.
- Cachear conteúdo na rede distribuída — Servir conteúdo estático e semi-estático a partir de nós de cache distribuídos, eliminando completamente as idas à origem para assets em cache.
- Usar HTTP/3 e QUIC — QUIC elimina a sobrecarga do setup de conexão TCP e lida com perda de pacotes sem bloqueio de cabeça de linha, reduzindo a latência em 10–30% em redes móveis.
- Terminar TLS próximo aos usuários — Os handshakes TLS exigem 1–2 idas e voltas. Terminar TLS em um nó distribuído próximo ao usuário reduz a latência do handshake de 200 ms (para uma origem distante) para menos de 10 ms.
- Minimizar o tempo de lookup DNS — Usar DNS anycast com pontos de presença globais. DNS lento adiciona entre 50 e 200 ms a cada nova conexão.
- Reduzir o tamanho do payload — Comprimir respostas com Brotli ou gzip. Payloads menores transmitem mais rápido pelo mesmo link.
- Reutilizar conexões (keep-alive) — Reutilizar conexões TCP e TLS estabelecidas elimina a latência do handshake para requisições subsequentes ao mesmo servidor.
Perguntas frequentes
O que é latência em redes? Latência em redes é o tempo que um pacote de dados leva para viajar de um ponto a outro e de volta, medido em milissegundos. É comumente expresso como RTT (Round-Trip Time). Menor latência significa tempos de resposta mais rápidos.
Qual é a diferença entre latência e largura de banda? Latência é o atraso antes que a transferência de dados comece — quanto tempo você espera antes de algo chegar. Largura de banda é quanto dado pode ser transferido por segundo — quanto você recebe assim que começa. Uma conexão de alta largura de banda ainda pode ter alta latência. Ambos importam para o desempenho, mas são independentes um do outro.
O que é RTT? RTT (Round-Trip Time) é o tempo que um sinal leva para viajar de um remetente a um receptor e de volta. RTT é a forma mais comum de medir a latência de rede. O comando ping mede o RTT.
O que causa alta latência? As causas mais comuns de alta latência são: (1) distância física entre o cliente e o servidor, (2) congestionamento de rede causando atrasos de filas, (3) excesso de saltos de rede entre a origem e o destino, e (4) tempos de processamento lentos do servidor.
Qual é uma boa latência para um site? Time to First Byte (TTFB) abaixo de 200 ms é considerado bom. TTFB acima de 500 ms é ruim. Os Core Web Vitals do Google recomendam TTFB abaixo de 800 ms para uma pontuação aprovada, mas abaixo de 200 ms para experiência de usuário ótima.
Qual é a diferença entre latência e ping? Ping é uma ferramenta de linha de comando que mede o RTT enviando pacotes ICMP echo a um destino e cronometrando a resposta. Latência é o conceito sendo medido. Ping é uma forma de medi-la.
O que é latência p95 ou p99? Latência P95 (percentil 95) significa que 95% das requisições são concluídas mais rápido que esse tempo. P99 significa que 99% são mais rápidas. A latência mediana (p50) pode parecer excelente enquanto p95/p99 são péssimas — essas latências de cauda representam usuários reais com experiências ruins. Para sistemas em produção, monitore p95 e p99, não apenas médias.
O edge computing reduz a latência? Sim. O edge computing reduz a latência processando requisições em servidores geograficamente próximos aos usuários em vez de rotear todo o tráfego para centros de dados centralizados. Um usuário em São Paulo atendido por um nó distribuído em São Paulo experimenta entre 5 e 15 ms de latência em vez de 150–300 ms para um servidor de origem distante.