Recentemente soube (via @ayubio) que em algumas regiões do Brasil uma simples consulta a um resolvedor DNS recursivo externo — tipo o 8.8.8.8 do Google ou o 1.1.1.1 do Cloudflare — pode levar mais de 150ms.

Isso muda consideravelmente o jogo quando você está decidindo entre arquiteturas como SPA (Single Page Application) e SSR (Server-Side Rendering) para um produto SaaS que terá usuários no país.

Por que o tempo de DNS importa

Cada hostname que a aplicação precisa resolver pode implicar em uma consulta DNS antes da conexão TCP/TLS.

Em redes com latência elevada ao resolvedor recursivo, cada nova resolução adiciona dezenas ou centenas de milissegundos ao tempo total de carregamento.

SPAs modernas tipicamente disparam múltiplas requisições a vários subdomínios e serviços (APIs, CDN, analytics, auth, feature flags, etc.). Se essas requisições requerem novas resoluções DNS ou cache com TTL curto, a latência se acumula.

Quando TTLs são curtos (ex.: 5 minutos, mas o Ayubi cita o TikTok com TTLs de até 1 minuto!!), o benefício do cache local é menor, levando a resoluções mais frequentes e variabilidade no desempenho.

SPA vs SSR

SPA (maioria dos web apps modernos)

Vantagens: experiência interativa após o carregamento inicial; menor carga no servidor para renderização repetida.

Desvantagens relevantes aqui: normalmente executa muitas chamadas do cliente a endpoints distintos; cada chamada pode depender de resolução DNS e de múltiplas conexões; impacto perceptível em redes com DNS lento, aumentando tempo até conteúdo útil e interatividade.

Efeito prático: maior sensibilidade a latência de infra distribuída (microservices, CDNs, terceiros), ou seja, quanto mais distribuído for o app mais lento será desde a camada mais básica que é o DNS.

SSR (server-side rendering)

Vantagens: o servidor consolida diversas chamadas e entrega HTML já renderizado; o cliente faz menos requisições imediatas ao carregar a página; resoluções DNS e latências entre serviços acontecem no backend — que você pode posicionar e gerenciar estrategicamente, por exemplo, dentro do mesmo provedor/região ou com resolvedores locais.

Desvantagens: maior custo/complexidade no servidor, menor responsividade para interações pós-load se a aplicação não for híbrida.

Efeito prático: menor número de resoluções DNS visíveis ao usuário final no primeiro carregamento, reduzindo impacto de latências de resolução no cliente. E se a “primeira impressão é a que fica”, como dizia a propanda de TV de quando eu era jovem…, um primeiro carregamento rápido estimula o usuário a pensar que está diante de um “site rápido” e que, por isso, ele não vai perder tempo ali.

Pensando o Brasil “na prática”

• Sempre assuma que o cliente pode ter alta latência de DNS; meça isso em regiões alvo.
• Preferência por SSR ou por um SSR híbrido para páginas públicas e de login/landing, minimizando chamadas do cliente no primeiro paint. “A primeira impressão é a que fica.”
• Centralize chamadas em um domínio/proxy para o carregamento inicial.
• Configure e teste TTLs, cache e uso de resolvers locais.
• Otimize dependências de terceiros no fluxo crítico de carregamento.
• Faça testes reais em redes móveis lentas e em ISPs regionais