Edge como orçamento de latência, não como destino

Edge computing melhora performance web quando move decisões simples e repetidas para perto do usuário, sem transformar a borda em um segundo backend completo. A pergunta certa não é se tudo deve rodar no edge, mas qual parte do caminho crítico precisa sair do datacenter para caber no orçamento de latência.

Onde a latência realmente aparece?

Em aplicações web, a demora percebida é a soma de DNS, conexão TCP ou QUIC, TLS, fila no servidor, consulta em banco, renderização, transferência, parse de JavaScript e hidratação no navegador. Mover uma função para São Paulo, Lisboa ou Frankfurt só ajuda se ela encurta uma etapa que está no caminho crítico do usuário.

Os Core Web Vitals dão uma régua prática. Para uma página ser considerada boa, o LCP deve ficar abaixo de 2,5 segundos, o INP abaixo de 200 ms e o CLS abaixo de 0,1. Edge pode ajudar nos dois primeiros: no LCP, entregando HTML e assets mais cedo; no INP, reduzindo dependência de JavaScript pesado e chamadas síncronas depois da interação.

Um exemplo comum: uma home pública com conteúdo editorial, preço regional e banner por campanha. Se cada visita consulta CMS, geolocalização, feature flag e banco de produtos antes de responder HTML, o problema não é falta de edge. O problema é que o servidor precisa pensar demais em toda requisição.

• Bom candidato para edge: redirecionamento por país, AB test leve, headers de segurança, cache de HTML, normalização de URL e autenticação simples por cookie assinado.
• Candidato perigoso: checkout, escrita transacional, cálculo financeiro, permissões complexas e qualquer fluxo que dependa de consistência forte.
• Não é edge: colocar a mesma API lenta em outro runtime e continuar chamando o banco central a cada request.

Quando vale colocar lógica na borda?

Vale quando a lógica tem três propriedades: é pequena, previsível e tolera dados ligeiramente defasados. Pequena significa executar em poucos milissegundos, sem dependências enormes. Previsível significa não depender de redes internas instáveis. Tolerar defasagem significa aceitar cache de segundos ou minutos sem quebrar o produto.

Na prática, isso combina bem com conteúdo e leitura. Uma página de produto pode usar cache público por 60 segundos, cache compartilhado por 10 minutos e revalidação em segundo plano por 24 horas. Isso reduz hits no origin, suaviza picos e entrega resposta rápida mesmo quando o backend está ocupado.

Cache-Control: public, max-age=60, s-maxage=600, stale-while-revalidate=86400
Surrogate-Key: product:123 category:tenis
Server-Timing: edge;dur=8, origin;dur=142, db;dur=37

Esse tipo de instrumentação muda a conversa. Sem Server-Timing, a equipe discute sensação. Com ele, dá para separar tempo na borda, tempo no origin e tempo de banco. Se o edge responde em 8 ms mas o origin leva 142 ms, o gargalo não está no worker. Se a borda sempre chama o origin, o cache está mal modelado ou a chave varia demais.

Protocolos também entram na conta. HTTP/3, padronizado no RFC 9114, usa QUIC sobre UDP e melhora cenários com perda de pacote e conexões móveis instáveis. TLS 1.3 reduziu rodadas de negociação em relação ao TLS 1.2.

O que quebra quando o edge vira mini-backend?

O erro clássico é distribuir computação sem distribuir dados. A função roda perto do usuário, mas precisa buscar sessão, permissão, preço, estoque e recomendação em uma região central. O resultado pode ser pior do que antes: mais hops, mais timeouts, mais logs espalhados e uma arquitetura difícil de depurar.

Outro risco é consistência. Cache invalidado por URL funciona bem para artigo, categoria e landing page. Já estoque, cupom e limite de uso exigem fonte de verdade clara. Se cada POP toma uma decisão diferente por alguns segundos, a performance melhorou no gráfico e piorou no negócio.

Há ainda diferenças reais de runtime. Ambientes de edge costumam favorecer APIs Web padrão, inicialização rápida e isolamento, mas limitam sockets, filesystem, pacotes nativos e tarefas longas. Código Node.js tradicional, com dependência de binários, conexão persistente a banco e uso pesado de memória, pode não migrar bem.

• Observe cold start: uma função rápida no laboratório pode variar quando roda em várias regiões com tráfego irregular.
• Controle cardinalidade de cache: variar por usuário, cookie e query string destrói hit rate.
• Defina fallback: se a configuração global falhar, a página deve continuar servindo uma versão segura.
• Centralize observabilidade: logs por região, trace id e métricas de cache precisam conversar entre si.

Uma regra útil: edge deve reduzir acoplamento no caminho de leitura, não criar uma nova malha de dependências síncronas. Se a função precisa chamar cinco APIs para decidir a resposta, provavelmente ela está no lugar errado. Se ela lê uma configuração replicada e escolhe entre duas respostas cacheadas, está perto do desenho ideal.

Comece pelo orçamento por tipo de página. Uma landing pública pode mirar TTFB abaixo de 200 ms em mercados principais e LCP abaixo de 2,5 s em conexão 4G boa. Um dashboard autenticado talvez aceite TTFB maior, desde que a primeira interação crítica fique abaixo de 200 ms.

Depois, classifique cada rota por perfil de dados. Rotas estáticas podem ser geradas no build e servidas por CDN. Rotas quase estáticas podem usar ISR, revalidação por webhook ou cache com stale-while-revalidate. Rotas dinâmicas de leitura podem usar edge para autenticar, selecionar região e encaminhar. Rotas transacionais devem ficar próximas do banco que garante consistência.

Por fim, trate edge como parte do pipeline, não como atalho. Headers, cache keys, invalidação, compressão Brotli, imagens responsivas, streaming de HTML e métricas de usuário real precisam entrar no mesmo checklist de deploy. A borda acelera o que já foi desenhado para ser acelerável. Ela não conserta modelo de dados confuso, frontend inchado ou API sem contrato de latência.

Perguntas frequentes

Edge computing melhora o SEO?

Pode melhorar indiretamente ao reduzir TTFB e acelerar o carregamento percebido, especialmente em páginas públicas. Mas SEO técnico ainda depende de HTML rastreável, conteúdo bem modelado, canonicals, links internos e estabilidade visual.

Qual a diferença entre CDN e edge computing?

CDN tradicional distribui arquivos e cache de respostas. Edge computing adiciona execução de lógica perto do usuário, como reescrita de URL, autenticação leve, personalização simples e roteamento por região.

Quando não devo usar edge computing?

Evite edge para fluxos transacionais, escrita em banco, regras financeiras e permissões complexas que exigem consistência forte. Nesses casos, a proximidade com a fonte de verdade costuma ser mais importante que alguns milissegundos a menos.

Edge substitui backend?

Não. Edge é uma camada de execução e entrega para partes específicas do caminho web. O backend continua responsável por dados, regras centrais, integrações profundas e consistência do sistema.