Next.js: o framework React para aplicações em produção

• O que é Next.js e por que ele domina o ecossistema React?
• Como funciona o App Router e o que muda com Server Components?
• Quais são as estratégias de renderização e quando usar cada uma?
• Quais recursos de Next.js economizam mais trabalho?
• Quando Next.js NÃO é a escolha certa?
• Como começar um projeto Next.js do jeito certo?

Next.js é o framework que transforma o React em aplicação completa: rotas, renderização no servidor, cache, otimização de assets e backend no mesmo projeto. Ele existe porque o React resolve a interface e deixa todo o resto por sua conta.

O que é Next.js e por que ele domina o ecossistema React?

Next.js é um framework de aplicações web mantido pela Vercel, lançado em 2016. Sua proposta é oferecer decisões prontas para as perguntas que todo projeto React precisa responder e a biblioteca não responde: como as URLs viram telas, onde o HTML é gerado, o que fica em cache, como o código é dividido e por onde a aplicação fala com o banco.

A adoção veio de um problema concreto. Aplicações de página única (SPA) entregam ao navegador um HTML quase vazio e um pacote de JavaScript que monta a tela. Isso significa primeira renderização mais lenta, dependência de execução de script para o conteúdo aparecer e desvantagem em indexação — três problemas que doem exatamente em sites cujo tráfego vem de busca orgânica.

Next.js inverte o padrão: o HTML sai pronto do servidor ou da build, e o JavaScript entra depois para adicionar interatividade. A versão estável atual, a 16.3, lançada em agosto de 2026, seguiu essa linha com foco em desempenho de build e navegação instantânea entre rotas.

Exemplo prático: um blog em SPA entrega ao rastreador um <div id="root"></div> e espera que ele execute o script. O mesmo blog em Next.js entrega o artigo inteiro em HTML na primeira resposta — que é o cenário em que a estrutura semântica do HTML realmente conta pontos.

Como funciona o App Router e o que muda com Server Components?

O App Router, padrão desde a versão 13, organiza a aplicação por pastas dentro de app/. Cada pasta é um segmento de URL, e arquivos com nomes reservados definem o comportamento daquele segmento:

• page.tsx — a interface acessível naquela rota.
• layout.tsx — envoltório compartilhado que não remonta na navegação entre filhos.
• loading.tsx — interface exibida enquanto o conteúdo carrega, ativando streaming automaticamente.
• error.tsx — limite de erro daquele segmento.
• route.ts — um endpoint de API na mesma árvore.

A mudança conceitual mais profunda são os React Server Components: por padrão, todo componente roda no servidor e não vai para o pacote do navegador. Você consulta o banco direto no componente, usa segredos sem expor e envia apenas o resultado renderizado.

import { db } from '@/lib/db';
import Comprar from './Comprar'; // esse tem 'use client'

export default async function Produto({ params }: { params: { slug: string } }) {
  // roda no servidor: nada disso vai para o navegador
  const produto = await db.produto.findUnique({ where: { slug: params.slug } });
  if (!produto) return <p>Produto não encontrado.</p>;

  return (
    <article>
      <h1>{produto.nome}</h1>
      <p>{produto.descricao}</p>
      <Comprar id={produto.id} preco={produto.preco} />
    </article>
  );
}

A regra prática para decidir: fica no servidor tudo que só lê e exibe; vai para o cliente apenas o que precisa de estado, evento ou API do navegador. Marcar um componente com 'use client' não o torna "só do cliente" — ele ainda é pré-renderizado no servidor, mas seu código passa a ser enviado ao navegador.

Exemplo prático: uma página de produto com dez componentes costuma ter dois interativos (botão de compra, galeria). Mantendo os outros oito no servidor, o pacote JavaScript da rota cai substancialmente — e o efeito aparece direto no tempo de interação medido pelos Core Web Vitals.

Quais são as estratégias de renderização e quando usar cada uma?

A granularidade por rota é o principal ganho técnico do framework. Você não escolhe um modo para o site inteiro; escolhe por página:

A decisão parte de duas perguntas: o conteúdo é igual para todo mundo? e com que rapidez ele precisa refletir mudanças? Igual para todos e tolerante a minutos de atraso: estática ou incremental. Diferente por usuário ou sensível ao segundo: dinâmica.

O streaming merece atenção porque resolve um problema específico: quando uma parte da página depende de uma consulta lenta, você não precisa segurar a página inteira. O que está pronto é enviado, e o restante chega depois, com <Suspense> marcando a fronteira.

Exemplo prático: em uma página de produto, ficha técnica e preço são estáticos com revalidação de dez minutos; o bloco "recomendados para você" é dinâmico e entra por streaming. O usuário vê o produto imediatamente e as recomendações aparecem meio segundo depois — em vez de esperar tudo.

Quais recursos de Next.js economizam mais trabalho?

Cinco entregam ganho desproporcional ao esforço de adoção:

1. next/image. Redimensiona, converte para formatos modernos, aplica lazy loading e reserva espaço para evitar deslocamento de layout. É a otimização de maior impacto em Core Web Vitals com menor esforço.
2. next/font. Baixa e serve fontes do mesmo domínio na build, elimina requisição a terceiros e remove o piscar de texto sem fonte.
3. Route Handlers. Endpoints de API na mesma árvore de rotas, com acesso a Request e Response padrão da web — dispensa um backend separado para casos simples.
4. Server Actions. Funções assíncronas que rodam no servidor e podem ser chamadas direto de um formulário, sem escrever endpoint nem fetch manual.
5. API de metadados. Título, descrição, Open Graph, canônico e alternates de idioma declarados por rota, com suporte a geração dinâmica — o que resolve, de forma tipada, boa parte do trabalho de SEO técnico.

Exemplo prático: trocar <img> por next/image em uma listagem com 30 miniaturas costuma reduzir o peso da página em mais de 60% e eliminar o deslocamento de layout — sem nenhuma mudança de arquitetura.

Quando Next.js NÃO é a escolha certa?

Quatro cenários em que o framework cobra mais do que entrega:

1. Aplicações totalmente autenticadas. Um painel administrativo atrás de login não tem SEO a ganhar e raramente precisa de renderização no servidor. Vite com React Router é mais simples, compila mais rápido e hospeda em qualquer lugar como arquivos estáticos.
2. Sites de conteúdo puro sem interatividade. Para documentação ou um site institucional, geradores como Astro ou Hugo entregam menos JavaScript e build mais rápida.
3. Times sem experiência com o modelo servidor-cliente. O App Router exige entender onde cada componente executa. Sem essa clareza, o resultado comum é 'use client' no topo de tudo — o que anula o benefício e mantém a complexidade.
4. Requisitos de hospedagem restritos. Fora da Vercel, recursos como revalidação sob demanda, middleware e cache incremental exigem configuração extra. É perfeitamente viável — em containers ou em qualquer nuvem —, mas some a conveniência de "funciona sozinho".

Exemplo prático: um ERP interno migrado para Next.js "por padronização" ganhou tempo de build seis vezes maior e uma camada de cache que ninguém usava. Todas as telas eram autenticadas: nenhuma linha de HTML gerado no servidor tinha valor ali.

Como começar um projeto Next.js do jeito certo?

Um roteiro que evita retrabalho:

1. Crie com npx create-next-app@latest e aceite TypeScript e ESLint. O TypeScript importa mais aqui do que na média: tipagem cobre a fronteira servidor-cliente, onde os erros silenciosos moram.
2. Desenhe as rotas antes de escrever componentes. A árvore de pastas é a arquitetura da aplicação; refatorá-la depois custa mais que planejá-la antes.
3. Comece tudo como Server Component. Adicione 'use client' só quando o erro do compilador exigir. O caminho inverso — assumir cliente por padrão — é o erro mais comum de quem vem do Pages Router.
4. Defina a estratégia de cache por rota conscientemente. Escrever export const dynamic = 'force-dynamic' para "resolver" um dado desatualizado costuma jogar fora justamente o ganho que motivou a escolha do framework.
5. Meça antes de otimizar. next build mostra o tamanho de cada rota; o Lighthouse mostra o efeito no usuário. Otimizar sem esses dois números é adivinhação.

Se o objetivo é ver a coisa funcionando de ponta a ponta, um bom exercício é conectar a aplicação a um banco real — o passo a passo de integração do MongoDB com Next.js cobre exatamente esse caminho.

Exemplo prático: um time que começou marcando todos os componentes com 'use client' para "evitar erros" acabou com um pacote maior que o da SPA anterior. A correção foi remover a diretiva de fora para dentro, mantendo-a apenas nos componentes com estado.

Conclusão

Next.js virou o padrão de fato para React em produção porque resolve, com decisões coerentes entre si, o conjunto de problemas que qualquer aplicação séria encontra: roteamento, renderização, cache, otimização de assets e a fronteira entre servidor e cliente. O App Router e os Server Components empurram o trabalho para o servidor, reduzem o JavaScript entregue e melhoram tanto a experiência quanto a indexação — desde que você entenda onde cada componente executa e escolha a estratégia de renderização por rota, e não por hábito. Para sites cujo tráfego vem de busca, ou aplicações que misturam conteúdo público e área logada, é uma escolha difícil de superar. Para painéis internos e ferramentas atrás de login, admita sem culpa: Vite entrega o mesmo resultado com menos peça móvel.