Latência sub-20ms: o KPI silencioso que define a percepção do seu produto

Você abre o app, clica num botão, espera. 200 milissegundos depois, a UI responde. Você não pensou muito sobre isso — pareceu instantâneo. Aceitável.

Você abre outro app, clica num botão similar. 800 milissegundos depois, a UI responde. Você não conseguiria cronometrar a diferença, mas seu cérebro registrou. O app pareceu “lento”. Você usa menos.

Essa diferença — 600ms quase imperceptível conscientemente — é a fronteira que separa um produto de sucesso de um produto que perde usuários. E essa fronteira é, em grande parte, latência de rede.

Esse post é sobre por que latência é o KPI mais silencioso e mais importante de experiência digital. Por que sub-20ms é a meta sagrada do UX moderno. E por que, pra usuários brasileiros, rodar no Brasil é a única forma estrutural de atingir isso.

A diferença que ninguém ensina: latência vs throughput

Antes de tudo, uma distinção que confunde mesmo engenheiros experientes.

Throughput é quanto dado passa por segundo. Sua banda larga “300 Mbps” é throughput. Quanto maior, mais rápido você baixa arquivos grandes.

Latência é quanto tempo um pacote leva pra ir de A pra B e voltar. É medida em milissegundos (ms). Quanto menor, mais rápido o “ping” — a resposta inicial.

A confusão acontece porque internet brasileira melhorou dramaticamente em throughput nos últimos 10 anos (de 1 Mbps pra 300 Mbps comum). Mas latência intercontinental não melhorou — ela é limitada pela velocidade da luz no cabo de fibra. Brasil pra Virginia/EUA são 140-200ms, sempre.

Analogia útil: throughput é a largura da estrada, latência é o comprimento da viagem. Você pode ter 8 faixas de estrada, mas se a viagem é de São Paulo a Manaus, vai demorar — independente da largura.

A regra dos 100ms (Doherty Threshold)

Em 1982, Walter Doherty publicou um paper na IBM Systems Journal chamado “The Economic Value of Rapid Response Time”. O estudo mostrava que produtividade de usuários técnicos (programadores, em sistemas mainframe) tinha um threshold mágico: quando o sistema respondia em menos de 400ms, o usuário entrava num estado de “fluxo”; acima disso, produtividade caía dramaticamente.

Em 2009, Google e Akamai replicaram estudos com usuários web. Achados:

0-100ms: percebido como instantâneo. Usuário não nota delay.
100-300ms: percebido como rápido. Levemente notável.
300-1000ms: percebido como lento. Frustração começa.
>1s: usuário muda de contexto mental, perde fluxo.

A meta moderna ficou em sub-100ms pra resposta inicial, idealmente sub-50ms pra interações de UI. Google internamente mede em P95 (95º percentil) — ou seja, 95% dos requests precisam estar abaixo do threshold.

Pra atingir sub-100ms no P95, você precisa que a latência de rede sozinha seja sub-30ms, porque o restante do tempo é gasto no servidor processando + renderizando no cliente. Sub-20ms te dá folga.

De onde vem a latência num request HTTP

Um único request HTTP simples tem várias camadas de latência somando:

DNS lookup (5-50ms na primeira vez, ~0 com cache)
TCP handshake (1× RTT)
TLS handshake (1-2× RTT — depende de TLS 1.3 ou 1.2)
Roteamento pela Internet (vários hops, latência por hop pequena mas soma)
Servidor processa o request (DB query, business logic, render)
Resposta volta (1× RTT)

Pra um usuário em São Paulo acessando servidor em us-east-1 (Virginia):

RTT médio: 140ms
DNS (com cache): ~0ms
TCP handshake: 140ms
TLS 1.3 handshake: 140ms (1× RTT em modo “0-RTT” otimizado; até 280ms em 1.2)
Processing: 50ms (DB query + lógica)
Resposta: 70ms (metade do RTT pra primeiro byte chegar)

Total: ~400-550ms pra primeiro request. Requests subsequentes na mesma conexão (com TCP/TLS reaproveitados) ficam em ~210ms (RTT + processing) — ainda lentos.

Mesma conta com servidor em Belo Horizonte:

RTT médio Brasil interno: 15-25ms
TCP handshake: 20ms
TLS handshake: 20ms
Processing: 50ms
Resposta: 10ms

Total: ~100-130ms. 4-5× mais rápido.

Multiplique por 10 requests por pageview (típico de app SPA com várias chamadas API), e a diferença vira segundos visíveis.

Medindo no real: BR app em us-east-1

Não precisa fazer só conta teórica. Quem mede no real (RUM — Real User Monitoring) tem dados públicos.

Cloudflare publica anualmente o “Year in Review” com latência média por país. Em 2024:

Brasil → Brasil (latência intra-país): 8-25ms (depende da região)
Brasil → US East: 138ms (média)
Brasil → US West: 178ms
Brasil → Europa Ocidental: 195ms
Brasil → Singapura: 305ms

Ferramentas como WebPageTest e PageSpeed Insights deixam você simular essas latências. Mas o dado mais útil é o seu próprio RUM — instrumente seu app com performance.timing ou ferramenta SaaS (DataDog RUM, Sentry Performance), e meça.

A surpresa pra muita gente é que uma boa parte do “tá lento” do app é latência de rede, não código mal otimizado. Otimizar o backend de 80ms pra 30ms não muda nada se o RTT é 140ms.

Onde otimização front-end falha

A resposta típica de quem percebe que o app “tá lento” é: “vamos otimizar front-end. CDN, image optimization, lazy loading, service worker.”

Tudo isso vale a pena, mas tem um teto. CDN resolve para conteúdo estático — HTML, CSS, JS, imagens. Isso fica cacheado perto do usuário. Ótimo. Bandwidth do primeiro paint é rápido.

Mas toda chamada de API original (POST /checkout, GET /api/dashboard, PUT /api/users/me) sempre vai pro servidor de origem. Não existe CDN pra resposta dinâmica autenticada. Cada uma dessas chamadas paga o RTT completo.

Pra app SPA típico:

Página inicial carrega: CDN serve em 50ms
App faz 5-10 chamadas API pra renderizar dashboard: cada uma paga 200ms+ se servidor é US
Total perceived performance: 1-3 segundos de “carregando…”

Otimização real exige reduzir o RTT da API. Ou seja: rodar o servidor perto do usuário.

A solução que ninguém quer admitir: rodar no Brasil

Aqui mora a parte política do problema. PaaS modernas (Vercel, Railway, Render) historicamente operam em us-east-1 ou us-west-2 — porque é onde a equipe deles está, onde o ecossistema cloud nasceu, onde o custo unitário é menor pra eles.

A solução técnica óbvia é: rodar no Brasil.

Opções:

AWS sa-east-1 (São Paulo): existe desde 2011. Funciona. Custo é 2× a região US (e ainda paga IOF + spread). Discutimos isso em Cloud no Brasil custa 78% a mais.
GCP southamerica-east1 (São Paulo): disponível desde 2017. Menos serviços que AWS sa-east-1.
Vercel: edge no Brasil: edge functions sim, mas database e backend full-stack continuam em US-East. Pra apps Next.js puros, ajuda muito; pra apps com backend pesado, ajuda pouco.
Provider BR moderno (Upuai): infra própria no Brasil, planos em BRL.

Não é necessariamente “tudo no Brasil ou tudo nos EUA”. Workloads diferentes podem morar em lugares diferentes. Mas pra a maioria dos requests do seu usuário brasileiro, você quer servidor brasileiro.

O caso Upuai: latência mensurada do BH para 5 regiões BR

A Upuai opera datacenter em Belo Horizonte/MG, conectado às 5 regiões nacionais via PTT-BH e trânsito IP nacional. Latência típica mensurada:

Origem do usuário	Latência média até DC Upuai BH	Comparação com us-east-1
São Paulo capital	~12ms	142ms (12× pior)
Rio de Janeiro	~14ms	145ms (10× pior)
Brasília	~10ms	155ms (15× pior)
Porto Alegre	~22ms	162ms (7× pior)
Recife	~32ms	127ms (4× pior)
Manaus	~45ms	165ms (3,7× pior)

Medições típicas via PTT-BH e roteamento nacional padrão, em condições normais de tráfego. Variações de até 20% são esperadas.

Pra 80% da população brasileira (Sudeste + Sul + Centro-Oeste), latência fica abaixo de 25ms. Pra Norte e Nordeste, abaixo de 50ms — ainda dentro do “instantâneo perceptual”.

Detalhamos o porquê do datacenter em BH em O datacenter em Belo Horizonte: por que importa onde seus bits dormem.

Outros KPIs que dependem de latência

Latência baixa afeta cascateando vários outros indicadores:

Time to First Byte (TTFB): primeiro byte da resposta. Latência alta = TTFB alto = Lighthouse score baixo = ranking de busca pior. Google usa TTFB como sinal de UX desde 2018.

Largest Contentful Paint (LCP): quando o maior elemento visível termina de renderizar. Core Web Vital crítico pra SEO. Servidor lento estoura LCP.

Conversão de checkout: Amazon publicou em 2009 que cada 100ms adicionais de latência derrubavam 1% das vendas. Empresas que mediram replicaram. Vale pra qualquer funnel.

Retention de produto: apps que parecem “lentos” perdem usuários nas primeiras sessões. É invisível analiticamente porque o usuário só desinstala — não te conta o motivo.

Quando latência não é o problema

Honestidade: existem cenários em que latência baixa não vai mudar nada.

Audiência fora do Brasil: se 80% dos usuários são americanos, datacenter em Virginia faz sentido. Datacenter BR pioraria pra eles.
Workload assíncrono/batch: cron jobs, processamento de filas, ETL. Não importa se demora 200ms a mais — não tem usuário esperando.
Apps server-side rendering pesado: se o servidor leva 800ms pra renderizar (DB lento, lógica pesada), reduzir 100ms de RTT é menos de 15% de melhoria.
Conteúdo majoritariamente cacheável: blog estático servido por CDN — onde está o servidor de origem importa pouco.

Pra esses casos, latência é fator secundário. Pra apps interativos brasileiros, é primário.

Perguntas frequentes

Como medir minha latência real hoje? Forma simples: abra o terminal e rode ping seu-app.com. Tire a média de 30 segundos. Forma melhor: instrumente RUM (Real User Monitoring) com Sentry, DataDog ou Cloudflare. Veja P50 e P95 de TTFB, distribuído por geografia do usuário.

CDN não resolve latência? CDN resolve latência de conteúdo estático. HTML, CSS, JS, imagens — sim, CDN é maravilhoso. Mas chamadas API dinâmicas (login, checkout, dashboard) sempre vão pro servidor de origem. CDN não cacheia POST autenticado nem GET com dados específicos do usuário.

Vercel Edge não resolve isso? Edge functions ajudam pra lógica leve (autenticação, redirect, A/B test). Mas se sua API faz query no banco, banco continua em us-east-1 (no caso típico) e você paga o RTT mesmo. Edge é melhoria, não solução completa.

HTTP/3 e QUIC não resolveram latência? HTTP/3 reduz handshake inicial (0-RTT em conexões já estabelecidas). Ajuda no first paint. Não muda RTT físico. Você ainda precisa de servidor próximo.

Se eu uso WebSocket ou Server-Sent Events, a latência ainda importa? Sim, importa pra abrir a conexão e pra cada mensagem. WebSocket sobre conexão US tem latência de 140ms em cada mensagem trocada — pra app de chat ou colaboração tempo real, isso é a diferença entre “fluido” e “engasgado”.

Posso ter parte do app no Brasil e parte nos EUA? Sim, e várias arquiteturas modernas fazem isso. Frontend + API “quente” no Brasil; processing pesado, ML, batch jobs nos EUA. Você roteia conforme caso de uso.

Latência é um dos pilares da experiência digital. Pra ver outros — custo, soberania, suporte — leia Cloud no Brasil custa 78% a mais, O datacenter em Belo Horizonte e Bare metal próprio vs cloud terceirizada.