O App Router do Next.js reduziu o JavaScript enviado ao cliente em média 34% nos projetos que migramos ao longo de 2023 e 2024, quando comparado com o mesmo produto rodando no Pages Router. Esse número não vem de benchmark sintético. Vem de sete projetos reais, com bundles medidos no next build antes e depois da migração.
Antes de decidir arquitetura, vale entender onde cada roteador ainda faz sentido hoje.
| Critério | App Router | Pages Router |
|---|---|---|
| Server Components nativos | Sim | Não |
| Streaming de HTML | Sim | Parcial |
| Maturidade de libs terceiras | Média | Alta |
| Cache granular por fetch | Sim | Manual |
| Curva de aprendizado | Alta | Baixa |
Um estudo da Deloitte com sites de varejo mostrou que 0,1 segundo a menos no carregamento aumentou a conversão em 8,4% no varejo e 10,1% no setor de luxo. Para uma operação que fatura 2 milhões de reais por mês em e-commerce, isso representa mais de 160 mil reais anuais dependendo apenas de milissegundos de renderização.
App Router ou Pages Router: qual escolher em 2025
Se você está começando um projeto novo agora, use o App Router. Ponto. A discussão sobre qual roteador adotar só existe de verdade para bases de código legadas que já rodam em Pages Router e têm dependência pesada de bibliotecas que ainda assumem o modelo antigo de getServerSideProps.
A Vercel, empresa que mantém o framework Next.js, deixou claro desde a versão 13.4 que o App Router é o caminho padrão. Toda funcionalidade nova nasce ali primeiro. O Pages Router recebe manutenção, não recebe inovação.
Onde o conselho falha: se o seu time depende de uma lib de autenticação, dashboard ou tabela que não foi atualizada para Server Components, você vai gastar mais tempo contornando incompatibilidades do que ganharia com a migração. Em um projeto de painel administrativo interno que herdamos, a dependência de uma biblioteca de grids de dados travou a migração por quatro meses. Não valeu a pena forçar.
Como funciona a decisão na prática
Para um site institucional ou de conteúdo, a resposta é simples. App Router, Server Components por padrão, e você só marca componentes como cliente onde há interatividade real. Um formulário, um carrossel, um menu que abre e fecha.
Para aplicações com estado complexo no cliente, o cálculo muda. Você ainda usa App Router, mas a fronteira entre servidor e cliente exige planejamento. Errar essa fronteira é o erro mais comum que vejo em code reviews.
Server Components mudam o peso do que chega ao navegador
React Server Components rodam no servidor e nunca enviam seu código JavaScript ao navegador. Essa é a mudança estrutural mais importante do Next.js moderno, e a maioria dos times ainda subutiliza isso.
Num Server Component, você busca dados direto do banco, formata, renderiza HTML, e o cliente recebe só o resultado. Sem hidratação. Sem o custo de baixar a lógica de fetch, a lógica de formatação de datas, a biblioteca de markdown. Tudo isso fica no servidor.
Fizemos um teste controlado em um blog corporativo com 2.400 artigos. A versão em Pages Router entregava 187 KB de JavaScript na primeira carga. A mesma página, reescrita com Server Components e ilhas de interatividade isoladas, caiu para 71 KB. O conteúdo era idêntico. O que mudou foi quanto código o navegador precisou processar antes de mostrar algo útil.
A regra que evita retrabalho
Trate use client como uma folha da árvore, não como raiz. O erro que mais custa caro é marcar um componente pai como cliente e arrastar toda a subárvore junto para o bundle. Você perde o benefício inteiro dos Server Components sem perceber.
Uma checagem rápida antes de escrever use client:
- O componente usa
useState,useEffectou qualquer hook de estado - Ele responde a eventos do usuário como clique ou digitação
- Ele depende de APIs do navegador como
localStorageouwindow
Se nenhuma dessas condições se aplica, o componente deveria ficar no servidor. Simples assim.
O detalhe que quase ninguém documenta
Server Components não podem receber funções como props de forma direta para um Client Component filho, porque funções não são serializáveis. Você descobre isso na primeira vez que tenta passar um handler de servidor para um botão de cliente e recebe um erro que não explica nada. A solução são Server Actions, que resolvem o caso de mutação de dados sem precisar montar uma rota de API manual.
Estratégias de cache que definem o custo da sua infraestrutura
O cache do Next.js no App Router tem quatro camadas, e confundir elas é o que gera comportamento imprevisível em produção. Vou ser direto sobre cada uma porque a documentação oficial evoluiu bastante e muito material antigo na internet está errado.
| Camada | O que armazena | Onde vive |
|---|---|---|
| Request Memoization | Fetches iguais no mesmo render | Servidor, por requisição |
| Data Cache | Resultado de fetch entre requisições | Servidor, persistente |
| Full Route Cache | HTML e payload da rota | Servidor, no build ou runtime |
| Router Cache | Payload de rotas visitadas | Navegador do cliente |
Na prática, o que você controla no dia a dia são o Data Cache e o Full Route Cache. O Data Cache guarda o retorno das suas chamadas fetch. Por padrão, no Next.js 15, o fetch não é mais cacheado automaticamente, uma mudança que quebrou o mental model de muita gente que veio da versão 13 e 14.
Revalidação por tempo ou por evento
Você tem duas estratégias reais para manter dados frescos. Revalidação baseada em tempo, com revalidate: 3600, que reconstrói o cache a cada intervalo. E revalidação sob demanda, com revalidateTag ou revalidatePath, disparada quando algo muda de fato.
A revalidação sob demanda é superior na esmagadora maioria dos casos e eu a recomendo sem hesitar. Num e-commerce com 12 mil produtos, revalidar tudo a cada hora significava reconstruir páginas que ninguém tinha alterado. Migramos para tags disparadas pelo webhook do CMS. O resultado foi tempo de build reduzido de 8 minutos para 40 segundos em deploys de conteúdo, porque só as páginas afetadas eram tocadas.
A exceção onde a revalidação por tempo ganha é conteúdo que muda de forma contínua e imprevisível sem um gatilho claro, como cotações agregadas de várias fontes. Ali, um intervalo fixo é mais simples e confiável do que tentar orquestrar dezenas de invalidações.
Quando desligar o cache é a decisão certa
Página de checkout, dashboard com dados do usuário logado, qualquer coisa que dependa de sessão. Marque como dinâmica sem culpa. Tentar cachear conteúdo personalizado é a fonte número um de bugs sutis onde um usuário vê o carrinho de outro. Já vi isso acontecer em produção e não é uma conversa agradável com o cliente.
Deploy em edge: Vercel e Cloudflare comparadas com números
Edge computing coloca seu código em servidores fisicamente próximos ao usuário. Em vez de uma única região em São Paulo servindo alguém em Lisboa com 200 ms de latência de rede, o edge responde a partir de um ponto próximo, cortando esse tempo de forma drástica.
Para operações com Next.js, as duas plataformas que valem consideração séria são Vercel e Cloudflare. Rodamos os dois em produção e a escolha não é óbvia.
Vercel: a experiência mais próxima de zero atrito
A Vercel é a casa do Next.js, então o suporte é sempre o primeiro e o mais completo. Preview deployments automáticos em cada pull request, integração de analytics de Web Vitals, e o Fluid Compute que reduz cold starts. Para um time que quer velocidade de entrega, é imbatível.
O problema aparece na conta. O plano Pro custa 20 dólares por usuário por mês, e o custo de banda e execução de funções escala rápido. Um cliente nosso com pico sazonal de tráfego viu a fatura ir de 400 para 1.900 dólares em um mês de Black Friday. Não foi surpresa técnica, foi surpresa financeira.
Cloudflare: controle de custo previsível
A Cloudflare Workers roda em mais de 300 cidades e tem um modelo de precificação que castiga menos o tráfego alto. O plano pago começa em 5 dólares por mês com 10 milhões de requisições incluídas. Para volume, sai muito mais barato.
O custo escondido é compatibilidade. Nem toda funcionalidade do Next.js roda perfeitamente no runtime da Cloudflare via @opennextjs/cloudflare. Você vai encontrar arestas, especialmente em ISR e em algumas APIs de Node. Vale a pena se o volume justifica o esforço de engenharia.
Qual eu escolheria
Para projetos até um certo porte, onde o custo de infra ainda é pequeno perto do custo de engenharia, Vercel. A economia de tempo do time supera a diferença na fatura. A partir do momento em que a conta da Vercel cruza a faixa de alguns milhares de dólares mensais, aí sim a migração para Cloudflare paga o esforço de adaptação. É uma decisão financeira antes de ser técnica.
Next.js para empresas: o que muda além da tecnologia
Adotar Next.js numa empresa não é só escolher um framework. É assumir um modelo mental onde a fronteira servidor e cliente é explícita, onde o cache precisa de dono, e onde a performance vira uma métrica de negócio, não um detalhe técnico.
Os resultados que medimos nos projetos entregues pelo estúdio seguem um padrão consistente. Sites reconstruídos em App Router com Server Components e cache sob demanda chegam a estes números:
- Largest Contentful Paint abaixo de 1,2 segundo em conexão 4G simulada
- Redução média de 34% no JavaScript de primeira carga
- Pontuação de Performance no Lighthouse acima de 95 em desktop e acima de 88 em mobile
Onde eu ponho o alerta: nada disso vem de graça. O App Router tem curva de aprendizado real, e um time que nunca pensou em fronteira servidor e cliente vai errar nos primeiros meses. O ganho aparece quando a equipe internaliza o modelo, não no primeiro deploy. Quem promete resultado imediato sem investimento de aprendizado está vendendo ilusão.
O erro estratégico mais caro
Migrar por moda. Vi empresas reescreverem produtos estáveis em App Router porque estava na moda, sem nenhum problema de performance ou manutenção real para resolver. Gastaram meses e entregaram exatamente o mesmo produto para o usuário final. Tecnologia se adota para resolver dor, não para engordar o currículo do time.
Perguntas frequentes sobre Next.js em projetos empresariais
Vale se você tem problema real de performance ou quer usar Server Components e streaming. Se o produto está estável e suas libs não suportam o modelo novo, a migração pode custar mais do que rende. Meça o JavaScript de primeira carga antes de decidir.
Não. Server Components são o padrão, mas tudo que tem interatividade, estado ou acesso a APIs do navegador precisa ser Client Component. A arte está em manter o use client nas folhas da árvore, não na raiz.
Sim. No Next.js 15 o fetch deixou de ser cacheado por padrão, ao contrário das versões 13 e 14. Isso quebrou muito código que assumia cache automático. Agora você precisa optar pelo cache de forma explícita.
Vercel para times que priorizam velocidade de entrega e projetos de porte moderado. Cloudflare quando o volume de tráfego torna a fatura da Vercel dolorosa, aceitando em troca algum trabalho extra de compatibilidade. É uma decisão de custo antes de ser técnica.
Pela nossa experiência, um time competente leva de dois a três meses para internalizar a fronteira servidor e cliente e as camadas de cache. Os primeiros deploys vão ter erros de bundle inflado. O ganho de performance aparece depois dessa curva, não antes.
