App Router vs Pages Router: qual escolher no Next.js em 2026

Se você está começando (ou repensando) um projeto em Next.js, é muito provável que já tenha esbarrado nessa dúvida: devo usar o App Router ou o Pages Router? A confusão é comum porque, pela primeira vez na história do framework, dois sistemas de roteamento convivem oficialmente no mesmo produto. E cada um tem uma filosofia, uma forma de organizar arquivos e até um jeito diferente de buscar dados.

A boa notícia: você não precisa virar especialista em arquitetura interna do React para tomar uma boa decisão. Basta entender o que cada roteador resolve, em que contexto ele brilha e quais os pontos de atenção. É exatamente isso que este artigo entrega, com linguagem acessível, exemplos reais e uma visão honesta sobre o que funciona em 2026.

Antes de partir para o comparativo, vale uma rápida contextualização sobre o que é o Next.js e por que essa decisão importa.

O que é o Next.js e por que existem dois roteadores

Next.js é um framework (uma espécie de "caixa de ferramentas pronta") para React, a biblioteca mais usada do mundo para construir interfaces web. O que o Next.js adiciona ao React é um conjunto de recursos prontos para produção, como:

• Roteamento baseado em arquivos (você cria um arquivo e a página aparece).
• Renderização no servidor (Server-Side Rendering.
• ou SSR.
• que é quando o servidor monta o HTML antes de entregar ao navegador).
• Geração estática (Static Site Generation.
• ou SSG.
• que gera as páginas uma vez e as reaproveita).
• Otimização de imagens.
• fontes e scripts.
• API Routes (endpoints para criar pequenos backends dentro do próprio projeto).

Até a versão 13, lançada em outubro de 2022, todo o roteamento do Next.js seguia o modelo conhecido como Pages Router: cada arquivo dentro da pasta pages/ virava automaticamente uma rota. Era simples, intuitivo e cobriu a maior parte das necessidades da comunidade por anos.

A partir da versão 13, a Vercel (empresa que mantém o Next.js) introduziu o App Router, baseado em uma tecnologia chamada React Server Components. A ideia é permitir que partes do código rodem exclusivamente no servidor, o que traz ganhos de performance, redução de JavaScript enviado ao navegador e novos padrões de organização.

A coexistência dos dois modelos é intencional: o App Router é o futuro recomendado, mas o Pages Router continua suportado para não quebrar a enorme base de projetos legados. Em 2026, a maioria das novidades e melhorias chega primeiro para o App Router, mas o Pages Router ainda é uma escolha viável em muitos cenários.

Conhecendo o Pages Router

O Pages Router é o modelo clássico do Next.js. Funciona com uma convenção simples: cada arquivo .js, .jsx, .ts ou .tsx dentro da pasta pages/ representa uma rota. Um arquivo pages/contato.js (ou .tsx) gera a URL /contato. Rotas dinâmicas usam colchetes, como pages/produtos/[id].tsx, que vira /produtos/123.

A maior parte do trabalho é feita por componentes React tradicionais, que rodam tanto no servidor quanto no cliente. Para buscar dados, existem funções específicas exportadas dentro de cada página:

• getStaticProps: executa no build (momento em que o site é preparado).
• gerando HTML estático, getStaticPaths: define quais rotas dinâmicas serão geradas estaticamente, getServerSideProps: executa a cada requisição.
• no servidor.
• com acesso a cookies.
• headers e parâmetros.

O Pages Router também introduziu o conceito de _app.js (componente raiz que envolve todas as páginas) e _document.js (estrutura HTML base). A separação entre cliente e servidor é feita usando a diretiva "use client" apenas quando alguma biblioteca exige interação direta no navegador.

Pontos fortes do Pages Router, Simplicidade

a curva de aprendizado é menor, especialmente para quem já trabalhou com React básico, Documentação extensa: anos de tutoriais, cursos e respostas em fóruns, Estabilidade: as APIs conhecidas permanecem estáveis, Liberdade de escolha: fica fácil decidir manualmente o que roda no servidor e o que roda no cliente, sem surpresas

Pontos de atenção do Pages Router

Toda página é, por padrão, um Client Component, o que pode inflar o JavaScript enviado ao navegador, Organização de dados compartilhados fica limitada, já que não há um modelo nativo de layouts aninhados com carregamento em paralelo, Novidades do framework chegam primeiro no App Router, o que pode reduzir o ritmo de evolução do Pages Router ao longo do tempo

Conhecendo o App Router

O App Router é o modelo mais novo. Ele vive dentro da pasta app/ (por convenção) e tem uma proposta diferente, baseada em três pilares:

1. Server Components por padrão: cada componente é renderizado no servidor, e apenas o que precisa de interatividade é enviado ao navegador
2. Layouts aninhados: cada pasta pode ter um arquivo layout.tsx que envolve todas as rotas abaixo, com estado preservado entre navegações
3. Streaming e Suspense: o conteúdo pode ser enviado em partes, mostrando o que está pronto antes do resto carregar

A estrutura básica usa o arquivo page.tsx para definir o conteúdo da rota e o layout.tsx para o que envolve esse conteúdo. Rotas dinâmicas continuam usando colchetes, e há pastas especiais como loading.tsx (tela de carregamento automática), error.tsx (tratamento de erros) e not-found.tsx (página 404 personalizada).

Para buscar dados, o App Router elimina as funções antigas e introduz o conceito de async components: você pode usar async e await diretamente dentro de um componente de servidor, chamando APIs, lendo banco de dados ou fazendo fetch de dados externos. Isso é possível porque o componente roda no servidor e não precisa esperar o navegador.

Pontos fortes do App Router

Performance melhor por padrão, já que menos JavaScript vai para o navegador, Layouts compartilhados com estado preservado, evitando remontagens desnecessárias, Streaming nativo, com React Suspense, melhorando a percepção de velocidade, Suporte a Server Actions, que permitem enviar formulários sem criar uma API tradicional, Mais recursos modernos, como partial prerendering, que combina SSG e SSR de forma inteligente

Pontos de atenção do App Router

Curva de aprendizado mais alta, especialmente para quem vem do React tradicional, Algumas bibliotecas ainda exigem ajustes para funcionar com Server Components, pois esperam rodar no navegador, O modelo mental é diferente: entender o que é servidor e o que é cliente exige mais atenção, A construção de aplicações ricas em interação, com muito estado no navegador, exige planejamento para não cair em erros comuns

Tabela comparativa: App Router vs Pages Router

A tabela abaixo resume, de forma direta, as principais diferenças entre os dois roteadores. Use como referência rápida na hora de decidir.

Quando usar cada um (cenários práticos)

A decisão raramente é binária. Em projetos novos, o App Router é a escolha natural na maioria dos casos. Mas há situações em que o Pages Router ainda faz sentido, especialmente em times que conhecem bem o modelo e não precisam dos recursos mais novos.

Quando o App Router é a melhor escolha

Projetos novos que começam do zero em 2026, Aplicações com foco em performance percebida, catálogos grandes, portais de conteúdo, Sistemas que precisam de layouts persistentes, como dashboards com menus laterais que não devem recarregar, Casos que se beneficiam de Server Actions, como formulários internos e áreas administrativas, Equipes dispostas a investir em treinamento para dominar o novo modelo

Quando o Pages Router ainda vale a pena

Projetos legados grandes, com muitas páginas já escritas no modelo antigo, Times com pouca familiaridade com React Server Components e que precisam entregar rápido, Aplicações simples, como sites institucionais, landing pages e blogs que não exigem streaming ou layouts aninhados, Casos em que a maior parte do trabalho é interação no navegador, como ferramentas SaaS com muito estado no cliente

E projetos híbridos?

É possível usar os dois modelos no mesmo projeto, mas exige cautela. O Next.js permite ter tanto a pasta app/ quanto a pasta pages/, mas as rotas ficam isoladas e o roteamento interno de uma não compartilha layouts com a outra. Para evitar confusão, o recomendado é escolher um único modelo por projeto, preferencialmente o App Router em novos desenvolvimentos.

Migração do Pages Router para o App Router

Migrar um projeto inteiro é uma decisão que deve considerar tempo, equipe e impacto em produção. Não existe uma ferramenta oficial de migração automática que faça tudo de uma vez, mas a Vercel disponibiliza um codemod (script que automatiza alterações no código) chamado next-codemod para ajudar em partes do processo, como a conversão de arquivos para o novo padrão.

Um caminho comum é fazer a migração em etapas:

1. Comece criando a pasta app/ ao lado da pasta pages/
2. Migre primeiro as rotas mais simples, como páginas estáticas e de baixo risco
3. Adapte a busca de dados para o modelo async, removendo getStaticProps e getServerSideProps aos poucos
4. Mova layouts compartilhados de _app.js para layout.tsx na raiz da pasta app/
5. Substitua componentes que precisam de interatividade por Client Components usando "use client" no topo do arquivo
6. Ajuste bibliotecas de terceiros que dependem de APIs do navegador, garantindo que rodem em Client Components
7. Remova a pasta pages/ apenas quando tudo estiver migrado e testado

Durante a migração, mantenha uma boa cobertura de testes automatizados, pois mudanças em roteamento podem afetar URLs, metadados e SEO. Ferramentas de análise estática e os próprios lints do Next.js ajudam a identificar problemas comuns.

Boas práticas para 2026

Independentemente do roteador escolhido, algumas práticas continuam fazendo diferença:

• Componentes pequenos e com responsabilidade única.
• Separação clara entre lógica de servidor e de cliente.
• Uso consciente de caches.
• tanto o do Next.js quanto o do navegador.
• Atenção a Core Web Vitals.
• que são indicadores de performance usados pelo Google para avaliar a experiência em uma página.
• Acessibilidade desde o início.
• não como ajuste final.

Se o seu projeto é novo, comece pelo App Router e invista em entender Server Components antes de adicionar interatividade. Se o projeto já existe, mantenha o Pages Router funcionando bem e avalie a migração aos poucos, priorizando áreas que mais se beneficiam do novo modelo, como layouts persistentes e streaming.

Perguntas Frequentes (FAQ)

1. O Pages Router será removido do Next.js?

Até a redação deste artigo, em 2026, a Vercel não anunciou descontinuação do Pages Router. Ele continua suportado e recebendo correções. A tendência é que o App Router receba a maior parte das novidades, mas projetos existentes não precisam migrar com urgência, a menos que queiram usufruir de recursos específicos do novo modelo.

2. Posso usar App Router e Pages Router juntos?

Sim, é tecnicamente possível, mas cada roteador vive em sua própria pasta e não compartilha layouts. Manter os dois em produção aumenta a complexidade sem ganho real, então o recomendado é usar apenas um por projeto. Em situações de migração gradual, a coexistência temporária é aceitável, mas o objetivo é convergir para um único modelo.

3. App Router é mais rápido que Pages Router?

Em muitos cenários, sim. Por usar Server Components por padrão, o App Router envia menos JavaScript ao navegador, o que reduz o tempo de carregamento e interação. Em páginas com muito conteúdo estático e pouca interatividade, a diferença pode ser significativa. Porém, a performance final depende de vários fatores, como qualidade do código, uso de imagens, caching e infraestrutura de hospedagem.

4. Preciso aprender React Server Components para usar o App Router?

Não é obrigatório aprender tudo de uma vez, mas entender o que é um Server Component e o que é um Client Component é fundamental para evitar erros comuns. O conceito é simples: Server Components rodam no servidor e não usam hooks do React, enquanto Client Components rodam no navegador e podem usar useState, useEffect e outros. Marcar um arquivo com "use client" no topo o torna um Client Component.

5. Vale a pena migrar um projeto pequeno do Pages Router para o App Router?

Depende do estágio do projeto e dos benefícios esperados. Em um projeto pequeno, ativo e com expectativa de crescimento, migrar costuma valer a pena, pois evita retrabalho futuro. Em um projeto pequeno, estável e sem planos de expansão, o custo de migração pode não compensar. Avalie caso a caso, considerando tempo da equipe, riscos e ganhos reais de performance ou produtividade.

Conclusão

A escolha entre App Router e Pages Router no Next.js não é sobre qual é melhor em termos absolutos, mas sobre qual é melhor para o seu contexto. O App Router representa a evolução natural do framework e oferece ganhos concretos de performance, organização e novos padrões como Server Actions e streaming. O Pages Router, por sua vez, é maduro, estável e continua sendo uma escolha válida, especialmente em projetos legados ou com equipes menos familiarizadas com o novo modelo.

Se você está começando um projeto novo em 2026, o caminho recomendado é o App Router, investindo tempo em entender Server Components e layouts aninhados. Se você mantém um projeto no Pages Router, mantenha-o funcionando bem e considere uma migração gradual para colher os benefícios do novo modelo sem ruptura.

Mais importante do que a tecnologia escolhida é a clareza dos seus objetivos, a qualidade do código e a capacidade da equipe de evoluir o produto com consistência. Tecnologia é meio, não fim.

Se você precisa de ajuda para colocar isso em prática, a Baita Site tem uma equipe especializada em sites, e-commerce, sistemas e inteligência artificial, com domínio total de Next.js e do ecossistema React. Fale com a gente e veja como podemos acelerar o seu projeto.

Referências consultadas, Documentação oficial do Next.js

https://nextjs.org/docs, Blog da Vercel: https://vercel.com/blog, React Server Components (repositório oficial): https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md, Guia de migração para App Router: https://nextjs.org/docs/app/upgrade/from-pages-to-app, Comunidade Next.js Brasil no Discord: https://discord.com/invite/nextjs, Artigo "Understanding the App Router" no blog da Vercel: https://vercel.com/blog/understanding-the-app-router