Next.js 16: a versão que para de fingir que o cache era simples

Se você já perdeu horas debugando por que aquela página não atualizava — ou por que o build estava demorando três minutos pra um projeto pequeno — o Next.js 16 foi lançado pensando em você.

Existe um momento específico na vida de todo dev que usa Next.js. Você faz uma mudança. Dá npm run build. Espera. Espera um pouco mais. O terminal vai contando os segundos enquanto você toma café. Você começa a questionar suas escolhas de vida.

E quando o build termina, você faz deploy — e a página está igualzinha a antes. Porque o cache não invalidou. E você não sabe por quê.

O Next.js 16 não resolve todos os problemas do universo. Mas resolve exatamente esses dois. E faz isso de um jeito que finalmente parece intencional — não um conjunto de configurações que você descobriu num thread do Reddit às 23h.

Turbopack: de "experimental" pra "é isso"

Desde o Next.js 13, o Turbopack era aquela promessa no horizonte. Mais rápido que o webpack, mas experimental demais pra usar em produção. Você testava, encontrava algum problema de compatibilidade, voltava pro webpack e ficava com a culpa.

No 16, acabou o período de namoro. O Turbopack é o bundler padrão — tanto em desenvolvimento quanto em produção. Sem flag, sem configuração, sem gambiarra.

Esses números não são de benchmark artificial. Mais de 50% das sessões de desenvolvimento em Next.js 15.3+ já estavam rodando Turbopack antes do lançamento oficial — o que significa que foi testado em escala real, com código real, antes de virar padrão.

Tem webpack customizado no projeto? O build vai falhar intencionalmente — pra não deixar a configuração silenciosamente ignorada. Você tem duas opções: migrar a config pra Turbopack, ou rodar explicitamente com next build --webpack enquanto faz a migração.

E tem mais: Turbopack File System Caching entrou em beta. Isso significa que os artefatos de compilação ficam salvos em disco entre os restarts do servidor de desenvolvimento. Num projeto grande, o primeiro next dev do dia vai ser lento uma vez. Depois disso, voa.

// next.config.ts — habilitar caching em disco (beta)const nextConfig = {  experimental: {    turbopackFileSystemCacheForDev: true,  },};export default nextConfig;

Cache Components: o cache que você consegue entender

Essa é a mudança mais importante do 16. E também a mais difícil de explicar sem parecer documentação.

Nas versões anteriores do App Router, o Next.js cacheava coisas implicitamente. Rotas estáticas eram cacheadas. Dados buscados com fetch eram cacheados. A regra geral existia, mas as exceções pareciam aleatórias — e quando algo não atualizava, você ficava no escuro tentando entender qual parte do sistema decidiu que aquele dado era "estático".

O Next.js 16 inverte isso. Por padrão, tudo é dinâmico. Nada é cacheado a não ser que você diga explicitamente que quer.

// next.config.ts — ativar Cache Componentsconst nextConfig = {  cacheComponents: true,};export default nextConfig;

Com isso ativado, você usa a diretiva "use cache" pra dizer exatamente o que quer cachear — uma página inteira, um componente específico, uma função que busca dados:

// Cachear uma função de busca de dadosasync function getPosts() {  "use cache";  const res = await fetch("https://api.blueprint.blog/posts");  return res.json();}// Cachear um componente específicoasync function Sidebar() {  "use cache";  const data = await getSidebarData();  return <nav>{data}</nav>;}

Também chegaram APIs mais explícitas pra invalidação: revalidateTag() com perfis de tempo e updateTag() pra invalidação instantânea após mutações — perfeito pra dashboards e formulários que precisam refletir dados na hora.

proxy.ts: adeus, middleware.ts

Esse aqui parece pequeno. Não é.

O middleware.ts era o arquivo que interceptava requisições antes de chegarem na sua aplicação. Funcionava — mas rodava no Edge Runtime, o que limitava o que você podia fazer. Sem Node.js nativo, sem algumas libs, sem acesso a certas APIs.

O proxy.ts substitui ele com uma diferença crucial: roda no Node.js. A migração é mecânica — renomeia o arquivo, renomeia a função exportada, e a lógica continua igual:

// Antes: middleware.tsexport function middleware(request) {  return NextResponse.redirect(new URL("/home", request.url));}// Depois: proxy.tsexport default function proxy(request) {  return NextResponse.redirect(new URL("/home", request.url));}

O middleware.ts ainda existe pra casos de Edge Runtime — mas está deprecated. Se você não tem um motivo específico pra Edge, vai pro proxy.ts.

React Compiler estável + React 19.2

Duas coisas que andavam juntas chegaram estáveis no 16.

O React Compiler faz memoização automática de componentes. Sabe aquele trabalho manual de decidir onde botar useMemo e useCallback? O compilador faz isso por você em tempo de build — sem mudar uma linha de código, sem nova sintaxe, sem configuração extra.

// next.config.ts — ativar React Compiler (não é padrão ainda)const nextConfig = {  reactCompiler: true,};export default nextConfig;

Já o React 19.2 traz três adições que vão aparecer gradualmente no seu dia a dia:

View Transitions — animações nativas entre navegações, sem biblioteca. useEffectEvent — uma forma limpa de extrair lógica não-reativa de Effects, resolvendo aquele problema clássico de closure stale. E Activity — componentes que "hibernam" mantendo o estado, perfeitos pra abas e modais que precisam persistir sem estar visíveis.

DevTools MCP: seu AI agent dentro do Next.js

Esse é o mais experimental da lista — mas o mais interessante dependendo de como você trabalha.

O Next.js 16 implementa o Model Context Protocol nativamente. Isso significa que um agente de AI conectado ao seu ambiente de desenvolvimento passa a ter acesso ao contexto real da aplicação: logs unificados de browser e servidor, stack traces automáticos, entendimento da rota ativa, comportamento de caching e rendering.

Em vez de copiar erro pra colar no chat, o agente vê o que está acontecendo. É o primeiro passo pra debugging assistido por AI que não depende de você traduzir o problema em palavras.

Como atualizar

A Vercel disponibilizou um codemod automático que cuida da maioria das migrações — incluindo renomear middleware.ts pra proxy.ts e ajustar APIs assíncronas de params:

npx @next/codemod@canary upgrade latest

Pra atualizar manualmente:

npm install next@latest react@latest react-dom@latest