Next.js 16 na prática: Cache Components no dia a dia

Cache Components, habilitado com cacheComponents: true no next.config.ts, muda a regra do jogo: por padrão, o Next.js agora exige que você seja explícito sobre o que pode virar HTML estático no build e o que é dinâmico de verdade.

A primeira vez que rodei o build depois de ativar, a página de orçamento (o chat interativo deste site) não quebrou — porque ela não lê nenhuma API externa nem cookies, só estado do React no navegador. Dado síncrono, vindo de módulo importado, continua sendo tratado como "previsível" e entra no shell estático automaticamente.

Onde eu esperava dor de cabeça e não tive: qualquer função async que só faz leitura de arquivo local (fs.readFileSync, import de JSON) também conta como previsível. Isso significa que dá pra manter o conteúdo do blog em arquivos TypeScript simples, sem precisar de 'use cache' nem Suspense em lugar nenhum — o build inteiro fica estático.

Onde eu teria dor de cabeça, se precisasse: qualquer coisa que leia cookies(), headers() ou searchParams precisa estar dentro de um <Suspense>, senão o overlay de desenvolvimento aponta exatamente a linha problemática. Prefiro isso a descobrir em produção.

A sacada central é: quanto mais fundo na árvore de componentes o dado dinâmico fica, mais da página consegue ser servida direto do CDN como HTML pronto. Vale a pena desenhar os componentes pensando nisso desde o início, não só quando o build começa a reclamar.