Edge computing: performance web sem mágica

Edge computing melhora performance web quando desloca decisões simples, cache e parte da execução para pontos próximos do usuário, em vez de concentrar tudo em uma única região cloud. O ganho real não vem de trocar servidor por buzzword, mas de reduzir ida e volta de rede, proteger a origem e entregar conteúdo dinâmico com menos dependência de um backend distante.

Na prática, edge é uma camada de infraestrutura distribuída entre o navegador e a aplicação principal. Ela pode estar em uma CDN tradicional, em runtimes como Cloudflare Workers, Fastly Compute, Vercel Edge Runtime ou AWS Lambda@Edge, ou em combinações desses serviços com cache, roteamento, autenticação leve e observabilidade.

Por que a distância ainda importa?

Mesmo com fibra, HTTP/3 e máquinas rápidas, rede continua sendo custo. Um usuário em Recife acessando uma aplicação hospedada só em us-east-1 pode atravessar milhares de quilômetros antes de receber o primeiro byte. Em páginas públicas, isso aparece como TTFB alto; em aplicações interativas, como cliques atrasados.

O Core Web Vitals traduz esse problema em métrica de produto. O Google considera uma boa experiência quando o LCP fica até 2,5 segundos, o INP até 200 milissegundos e o CLS até 0,1. Edge computing não resolve layout instável nem JavaScript excessivo, mas pode atacar TTFB, tempo de download e disponibilidade.

A diferença entre CDN e edge computing é execução. CDN clássica distribui arquivos: HTML estático, CSS, JavaScript, imagens e fontes. Edge computing adiciona lógica: uma função pode decidir idioma, moeda, cache, redirecionamento, cabeçalho de segurança ou variante de conteúdo antes de bater na origem.

• CDN: entrega arquivos próximos do usuário.
• Edge function: executa lógica curta próxima do usuário.
• Origem: cuida de dados complexos, transações e regras críticas.
• Banco de dados: precisa de estratégia própria; compute no edge não torna um banco regional global.

O que faz sentido colocar no edge?

O melhor uso de edge é mover para perto do usuário aquilo que é frequente, barato de executar e pouco dependente de estado forte. Isso inclui páginas públicas, APIs de leitura com cache, feature flags, redirecionamentos, headers, autenticação inicial e personalização superficial.

Um e-commerce pode servir home, categorias e páginas de produto em cache no edge, com revalidação a cada 60 ou 300 segundos. Carrinho, checkout e pagamento continuam na origem, porque exigem consistência, auditoria e controle transacional.

Um exemplo simples em Cloudflare Workers mostra a ideia: cachear uma resposta de leitura por 60 segundos e evitar chamadas repetidas à origem.

export default {
  async fetch(request, env, ctx) {
    const cache = caches.default;
    const cacheKey = new Request(request.url, request);

    let response = await cache.match(cacheKey);
    if (response) return response;

    response = await fetch(request);
    response = new Response(response.body, response);
    response.headers.set("Cache-Control", "public, max-age=60, stale-while-revalidate=300");

    ctx.waitUntil(cache.put(cacheKey, response.clone()));
    return response;
  }
};

O código é pequeno, mas a decisão arquitetural por trás dele é grande: aceitar que uma resposta pode ficar 60 segundos em cache e até 300 segundos em modo stale while revalidate. Para catálogo, blog, documentação e landing pages, isso é razoável. Para saldo bancário, estoque crítico ou permissão administrativa, não é.

Também vale usar edge para segurança de borda. Rate limiting, bloqueio por país, normalização de URL e headers como Content-Security-Policy podem ser aplicados antes da origem gastar CPU.

Onde edge computing costuma dar errado?

O erro mais comum é tratar edge como substituto universal do backend. Runtimes de edge têm limites deliberados: tempo de execução curto, APIs Node.js parciais ou ausentes, restrições de filesystem, cold starts diferentes e bibliotecas compatíveis com Web APIs. Um pacote que funciona em Node.js 22 no servidor pode falhar em um runtime baseado em V8 isolates.

Outro problema é o banco. Se a função roda em São Paulo, Frankfurt e Tóquio, mas o PostgreSQL está apenas na Virgínia, cada requisição dinâmica ainda cruza o mundo. A aplicação pode ter compute distribuído, mas o gargalo virou conexão com dados. Para leitura global, entram réplicas, cache, KV stores e bancos serverless com replicação. Para escrita forte, entram filas, particionamento e desenho explícito de consistência.

Antes de mover algo para o edge, faça três perguntas:

1. Essa resposta pode ser cacheada por segundos ou minutos?
2. A lógica depende de bibliotecas pesadas, filesystem ou APIs específicas de Node?
3. O dado precisa ser globalmente consistente no mesmo instante?

Se a resposta for sim para cache e não para consistência forte, edge provavelmente ajuda. Se a regra depende de transação, sessão sensível ou escrita coordenada, mantenha na origem e otimize o caminho ao redor.

Como desenhar uma infraestrutura web mais rápida?

Uma boa arquitetura edge começa simples. Primeiro, coloque assets estáticos em CDN com cache longo e nomes versionados: app.8f3a1.js, styles.91c2.css. Depois, separe páginas públicas de rotas autenticadas. Em seguida, adicione cache de HTML ou API onde o negócio tolera defasagem. Só então mova lógica para edge functions.

Para sites de conteúdo, uma meta pragmática é TTFB abaixo de 200 ms em regiões prioritárias e cache hit ratio acima de 80% nas páginas públicas. Para SaaS, a prioridade pode ser reduzir chamadas bloqueantes, comprimir payloads, usar HTTP/2 ou HTTP/3 e evitar telas dependentes de cinco serviços internos em série.

Observabilidade fecha o ciclo. Métricas por região, taxa de cache hit, p95 e p99 de latência, erros por runtime e logs amostrados dizem se a borda está ajudando ou apenas escondendo complexidade.

O caminho mais saudável é pensar em camadas: navegador rápido, CDN previsível, edge para decisões curtas, origem para regras fortes e banco desenhado para o padrão real de leitura e escrita. Edge computing é excelente quando reduz distância e repetição. Quando tenta substituir modelagem de dados, testes e observabilidade, só muda o lugar do problema.

Perguntas frequentes

O que é edge computing na web?

É a execução de cache, regras e funções em servidores próximos do usuário, geralmente dentro da rede de uma CDN ou plataforma distribuída. O objetivo é reduzir latência e aliviar a origem.

Edge computing substitui backend?

Não. Edge funciona melhor para lógica curta, leitura cacheável, roteamento e personalização leve. Transações, escrita crítica e regras complexas continuam fazendo mais sentido no backend principal.

Edge computing melhora Core Web Vitals?

Pode melhorar principalmente TTFB e ajudar o LCP quando a página depende de HTML ou dados entregues mais rápido. Não resolve sozinho JavaScript pesado, imagens mal dimensionadas ou problemas de layout.

Quando não usar edge computing?

Evite edge quando a rota depende de consistência forte, bibliotecas incompatíveis com o runtime, processamento longo ou acesso frequente a um banco regional distante. Nesses casos, otimizar a origem costuma ser mais simples.