nextjs.org

Next.js é um framework React para criar aplicações web full-stack. O React fornece o modelo de componentes para interfaces de usuário; o Next.js acrescenta roteamento, renderização, convenções de acesso a dados, recursos de servidor, compilação, empacotamento, cache e ferramentas voltadas para produção.

O assunto principal é o framework, não seu domínio. nextjs.org é o site oficial onde os visitantes podem encontrar documentação mantida, guias, links da comunidade e informações sobre o projeto.

O Next.js é mais relevante quando uma equipe deseja desenvolver com React e, ao mesmo tempo, oferecer mais do que uma interface executada somente no navegador. Um projeto pode conter páginas pré-renderizadas, respostas geradas no momento da requisição, acesso a dados no servidor, endpoints no estilo de APIs e componentes interativos executados no navegador.

O que o Next.js acrescenta ao React

O React ajuda os desenvolvedores a descrever interfaces como componentes, mas não prescreve uma arquitetura completa de aplicação. O Next.js fornece convenções para mapear arquivos para rotas, decidir onde o código é executado, carregar dados, produzir respostas e preparar uma aplicação para implantação.

Portanto, seu valor é mais amplo do que a renderização no servidor. Uma aplicação Next.js pode usar vários métodos de renderização e entrega, às vezes dentro do mesmo projeto. O framework coordena esses métodos em torno do React, em vez de forçar todas as rotas a seguirem um único modelo.

Um resumo útil dessa divisão é:

• O React define componentes, estado, props e composição da interface.
• O Next.js define rotas, layouts, opções de renderização, pontos de entrada no servidor e comportamento de build.
• A aplicação define suas regras de dados, limites do cliente, política de cache e requisitos de implantação.
• O ambiente de hospedagem determina quais recursos do ambiente de execução estão disponíveis e como funcionam.

Essa separação é importante ao comparar o Next.js com uma aplicação React no cliente, um gerador de sites estáticos ou outro framework web. O framework oferece uma ampla variedade de recursos, mas um projeto só se beneficia dos recursos que utiliza bem.

Componentes de servidor e de cliente

No App Router, layouts e páginas são Server Components por padrão. Server Components são executados em um ambiente de servidor e podem realizar operações de dados no servidor sem enviar sua implementação de componente ao navegador.

Client Components são usados quando uma parte da interface precisa de estado no navegador, manipuladores de eventos, efeitos ou APIs disponíveis somente no navegador. Os desenvolvedores marcam um limite do cliente com a diretiva use client, e os componentes abaixo desse limite passam a fazer parte do grafo de módulos do lado do cliente.

Pergunta	Server Component	Client Component
Onde a lógica do componente é executada?	No ambiente de renderização do servidor	No navegador, após ser incluída no pacote do cliente
Pode usar estado do navegador ou manipuladores de clique?	Não	Sim
Pode usar diretamente APIs disponíveis somente no navegador?	Não	Sim
O código do componente é enviado ao navegador?	Não como código de componente do cliente	Sim
Função típica	Conteúdo baseado em dados, layouts e composição no servidor	Formulários, menus, editores, filtros e outros controles interativos

Uma rota não precisa escolher exclusivamente um dos tipos. Um Server Component pode renderizar conteúdo e compor Client Components selecionados para as partes interativas da página. Isso permite que as equipes adicionem JavaScript no navegador em torno de necessidades específicas, em vez de tratar a rota inteira como uma aplicação de cliente.

O limite ainda exige cuidado. Colocar uma grande subárvore de componentes atrás de use client pode enviar mais JavaScript ao navegador, enquanto dividir cada pequeno controle em um limite separado pode dificultar a compreensão do código. Páginas representativas devem ser medidas, em vez de avaliadas apenas pelo rótulo do framework.

Server Components também são diferentes da estratégia de entrega de uma rota. Um Server Component pode contribuir para uma saída pré-renderizada ou participar de uma renderização dinâmica. Descrever um componente como sendo do lado do servidor não informa, por si só, se a rota é gerada durante um build, atualizada posteriormente ou produzida para cada requisição.

App Router e Pages Router

Atualmente, o Next.js documenta dois sistemas de roteamento. O App Router é o sistema mais recente e incorpora recursos do React, como Server Components. O Pages Router é o sistema mais antigo e continua sendo compatível.

Área	App Router	Pages Router
Estrutura principal de rotas	O diretório app	O diretório pages
Modelo padrão de componentes	Layouts e páginas são Server Components	Usa o modelo de páginas anterior do Next.js
Interface compartilhada	Layouts aninhados são uma convenção central	Geralmente composta por meio de padrões de aplicação e página
Melhor ponto de partida	Novos projetos que adotam a arquitetura atual	Aplicações existentes ou dependências criadas em torno das APIs do Pages Router

Uma migração envolve mais do que renomear pastas. O código do App Router introduz um modelo de componentes com prioridade para o servidor e padrões diferentes para layouts, acesso a dados, estados de carregamento e comportamento de rotas. As equipes devem identificar essas mudanças conceituais antes de converter uma aplicação madura.

Novos projetos geralmente devem estudar primeiro a documentação do App Router, porque ela explica o modelo atual do framework. Aplicações existentes que usam o Pages Router devem avaliar a migração com base nos benefícios reais, nas dependências, no esforço de testes e no custo de manutenção, em vez de tratar a continuidade do suporte como um defeito.

A documentação e os exemplos podem se destinar a apenas um roteador. Antes de copiar uma implementação, os desenvolvedores devem confirmar qual roteador ela utiliza e se as APIs mencionadas se aplicam ao projeto.

Renderização, cache e revalidação

O Next.js não renderiza todas as páginas da mesma maneira. Uma rota pode ser preparada antes da chegada de um visitante, gerada com informações específicas da requisição, armazenada em cache ou atualizada de acordo com uma política de revalidação.

Necessidade da rota	Abordagem provável de entrega	Pergunta a verificar
As entradas são conhecidas antecipadamente	Saída pré-renderizada	Qual evento deve fazer a saída mudar?
A saída depende de cookies, cabeçalhos ou dados da requisição	Renderização dinâmica	Alguma parte do trabalho ainda pode ser armazenada em cache com segurança?
O conteúdo muda em uma programação controlada	Saída em cache com revalidação	Quanto tempo a resposta pode permanecer desatualizada?
Nenhum recurso exclusivo do servidor é necessário	A exportação estática pode ser adequada	Todas as rotas e todos os ativos são compatíveis com as limitações da exportação?

O cache não é um único interruptor que possa ser compreendido independentemente do acesso a dados. As equipes precisam saber quais operações são armazenadas em cache, quais rotas se tornam dinâmicas e como ocorre a invalidação ou revalidação. Essas regras devem ser testadas com mudanças realistas de conteúdo.

Isso é especialmente importante para páginas autenticadas, preços, estoque, painéis e outras informações com requisitos explícitos de atualização. Servir uma saída em cache pode ser vantajoso, mas somente quando as regras de correção da aplicação permitirem.

O desempenho e a visibilidade nas buscas não devem ser inferidos apenas pelo rótulo da renderização. A pré-renderização pode reduzir o trabalho no momento da requisição, e a renderização no servidor pode fornecer HTML inicial significativo, mas os resultados reais dependem da estrutura da página, dos ativos, da latência dos dados, do JavaScript no navegador, do cache e do comportamento da implantação.

Exportação estática e requisitos do ambiente de execução

O Next.js pode gerar uma exportação estática quando o projeto não depende de recursos do framework disponíveis somente no servidor. Os arquivos HTML, CSS, JavaScript e ativos resultantes podem ser servidos por uma infraestrutura compatível com arquivos estáticos comuns.

A saída estática ainda pode incluir Client Components. A entrega estática descreve como o resultado do build é hospedado; ela não significa que todas as interfaces precisam ser não interativas. O código executado no navegador ainda pode fornecer estado, eventos e outros comportamentos do cliente.

Antes de escolher a exportação estática, verifique se o projeto não exige:

• Respostas geradas com dados do servidor específicos da requisição.
• Comportamento de rota que dependa de um ambiente de execução ativo do Next.js.
• Recursos de imagem, roteamento ou servidor sem suporte.
• Regras de atualização que não possam ser atendidas por um novo build ou outro processo de atualização compatível.
• Endpoints de servidor que precisem ser executados junto à aplicação.

Quando esses recursos são necessários, a aplicação precisa de um ambiente de execução compatível. Isso não exige implantação na Vercel: o guia oficial de implantação documenta a auto-hospedagem e os adaptadores de plataforma. O suporte varia de acordo com a plataforma, portanto a compatibilidade deve ser verificada em relação aos recursos específicos em uso.

Route Handlers e endpoints do lado do servidor

No App Router, Route Handlers permitem que uma aplicação defina manipuladores de requisições HTTP usando conceitos padrão de requisição e resposta. Eles são úteis para endpoints que fazem parte da aplicação, incluindo processamento de formulários, webhooks, respostas de dados ou callbacks de integração.

Um Route Handler não é automaticamente o local certo para todos os sistemas de backend. As equipes ainda devem decidir como autenticação, autorização, validação, controles de taxa, trabalho durável e tratamento de erros serão gerenciados. Serviços de longa duração ou dimensionados de forma independente podem ser mais bem separados da aplicação web.

Uma análise prática pergunta:

1. O endpoint precisa acessar o código da aplicação ou tipos compartilhados?
2. Ele exige segredos disponíveis no momento da requisição ou dependências exclusivas do servidor?
3. A implantação de destino pode executar o manipulador conforme documentado?
4. Qual comportamento de cache é correto para cada método HTTP e resposta?
5. Um serviço separado proporcionaria responsabilidade ou dimensionamento mais claros?

Route Handlers tornam conveniente a composição full-stack, mas essa conveniência não elimina as responsabilidades normais de segurança e design de APIs.

Onde o Next.js é uma escolha prática

O Next.js é um forte candidato para equipes que já estão familiarizadas com React e precisam de roteamento da aplicação e recursos de servidor na mesma base de código. Ele também pode ser adequado para produtos cujas diferentes rotas tenham necessidades de entrega substancialmente diferentes.

Casos comuns incluem:

• Áreas de conta e painéis com dados do servidor e controles interativos.
• Experiências de comércio ou catálogo que combinam conteúdo estável com informações dependentes da requisição.
• Sites de documentação ou marketing que também contêm fluxos de trabalho da aplicação.
• Produtos que precisam reunir respostas HTML, interação no cliente e endpoints de servidor.
• Aplicações React cujas rotas se beneficiam de políticas separadas de cache e renderização.

O framework pode representar mais infraestrutura do que um site de conteúdo simples exige. Uma equipe que publica principalmente artigos estáticos deve comparar suas necessidades com ferramentas voltadas à entrega de conteúdo, especialmente se apenas uma pequena parte do site precisar de interação com React.

O Next.js também pode ser uma escolha ruim quando a equipe não consegue atender a seus requisitos de ambiente de execução, não deseja conceitos de renderização específicos do framework ou teria dificuldade para manter limites claros entre servidor e cliente. A flexibilidade só é valiosa quando a arquitetura permanece compreensível.

Comparando o Next.js com Astro e outras opções

Next.js e Astro são frequentemente avaliados para projetos que combinam conteúdo com elementos interativos, mas seus padrões e modelos mentais são diferentes. A escolha adequada depende das rotas reais, não de uma afirmação genérica de que um framework é mais rápido ou melhor.

Para uma comparação útil, crie a mesma página representativa em cada candidato e registre:

• Quanto JavaScript chega ao navegador antes e depois da interação.
• Como os dados são carregados e como a atualização é controlada.
• Se são necessários recursos de ambiente de execução no servidor.
• Como roteamento, layouts, formulários e estados de erro são implementados.
• Se o host de destino oferece suporte a todos os recursos necessários.
• Com que facilidade a equipe consegue testar e explicar a arquitetura resultante.

O Astro merece consideração especial para sites orientados por conteúdo, nos quais a maior parte da saída pode permanecer estática e as ilhas interativas são limitadas. O Next.js se torna mais atraente quando o React é o modelo central da aplicação e recursos de servidor e cliente precisam ser compostos em todo o produto.

Nenhuma das comparações prevê uma pontuação de desempenho. Imagens, fontes, scripts de terceiros, escolhas de componentes, latência dos dados e limites do cliente podem superar a influência dos padrões do framework.

Origens, governança e comunidade

A página oficial de governança afirma que a equipe da Vercel criou o Next.js em 2016. Ela também informa que a equipe principal da Vercel lidera a pesquisa e o desenvolvimento do projeto. Essa é uma declaração de origem e governança no nível da equipe; ela não deve ser substituída por uma afirmação sem fundamento sobre um fundador individual.

Conforme documentado nas páginas de governança e documentação disponíveis em 27 de agosto de 2026, os caminhos de participação pública do projeto incluem:

• O repositório oficial no GitHub para código-fonte, problemas e atividades do projeto.
• GitHub Discussions para perguntas e discussões de RFCs da comunidade.
• O Discord do Next.js para suporte gratuito da comunidade.
• Documentação mantida para o App Router e o Pages Router.

Esses canais oferecem diferentes tipos de ajuda. A documentação deve ser a primeira referência para o comportamento do framework, o Discussions pode revelar propostas e perguntas compartilhadas, e o Discord pode apoiar conversas da comunidade. Nenhum deles substitui testes específicos do projeto ou o processo de suporte à produção da própria equipe.

Uma lista de verificação para a decisão

Antes de adotar o Next.js, as equipes devem responder a estas perguntas com um protótipo funcional:

• Quais rotas são estáticas, dinâmicas, armazenadas em cache ou revalidadas?
• Quais componentes realmente exigem estado, efeitos, eventos ou APIs do navegador?
• Quanto JavaScript do cliente cada rota representativa envia?
• Quais endpoints pertencem a Route Handlers e quais devem ficar em outro lugar?
• A plataforma de destino pode executar todos os recursos necessários do Next.js?
• Como serão gerenciados a atualização do cache, falhas, logs e implantações?
• A equipe entende as diferenças entre o roteador escolhido e os exemplos escritos para o outro roteador?

O Next.js trata da aplicação do React em uma aplicação web completa, escolhendo deliberadamente onde o trabalho acontece e como cada rota é entregue. Sua flexibilidade documentada é considerável, mas ela não garante desempenho, resultados de busca, baixo custo operacional ou simplicidade arquitetural. Esses resultados devem ser estabelecidos por meio de implementação e medição.