Os redirects não prejudicam a performance — caminhos bloqueantes prejudicam

Os redirects são frequentemente tratados como um anti-pattern de performance web. Ferramentas como PageSpeed e Lighthouse reforçam esta ideia ao sinalizarem redirects como algo a evitar. Com o tempo, isto transforma-se numa regra simplificada: “redirects são maus”.

O problema não está no aviso em si, mas na falta de contexto técnico por detrás dele.

Quando compreendemos o verdadeiro custo dos redirects, a conversa torna-se mais clara, mais precisa e muito menos dogmática.

O que o PageSpeed está realmente a penalizar

Os redirects não são inerentemente lentos.

O que prejudica a performance é adicionar ciclos extra de rede no caminho crítico antes do browser receber o HTML.

Isto acontece normalmente quando:

• Existem múltiplos redirects encadeados

• Os redirects ocorrem antes da resposta HTML

• As decisões de redirect dependem de I/O externo (APIs, CMS, bases de dados)

Cada redirect adiciona um novo ciclo de request–response. Estes saltos acumulam latência antes do rendering sequer começar.

O impacto é visível em:

• TTFB, devido ao atraso na resposta do servidor

• LCP, porque a entrega do HTML é adiada

• Experiência mobile, onde a latência é amplificada

Um cenário realista em Next.js que cria múltiplos saltos

Um padrão comum em aplicações modernas combina redirects dinâmicos com verificações de autenticação.

Por exemplo:

1. Uma rota é interceptada por middleware

2. Uma consulta a um CMS determina um redirect

3. O pedido volta a entrar no middleware

4. A lógica de autenticação desencadeia outro redirect

Antes de qualquer HTML ser devolvido, o browser já seguiu vários saltos.

Mesmo a correr na edge network do Next.js, este fluxo:

• aumenta o TTFB

• afeta indiretamente o LCP

• degrada a latência em mobile

O problema não é o framework. É o caminho de entrega.

Quando os redirects são praticamente gratuitos

Os redirects deixam de ser um problema de performance quando são:

• Resolvidos na edge, perto do utilizador

• Únicos e determinísticos, sem encadeamentos

• Permanentes (301 / 308), permitindo cache agressivo no browser

• Independentes de I/O externo pesado

Nestes casos, o custo do redirect é pago uma única vez — ou nem chega a ser sentido — e desaparece do caminho crítico em navegações seguintes.

Conclusão

Os redirects não são vilões da performance. São essenciais para SEO, evolução de produto e aplicações à escala.

Tornam-se um problema apenas quando bloqueiam a entrega, criam saltos desnecessários ou dependem de decisões lentas no momento do request.

Compreender esta diferença evita arquiteturas frágeis e substitui decisões baseadas em medo por soluções fiáveis e mensuráveis.