Cache Mais Inteligente no Next.js: Renderização Parcial e Componentes Reutilizáveis

Você construiu uma aplicação Next.js com App Router. As requisições de dados funcionam. As páginas renderizam. Mas você não tem certeza se sua estratégia de cache está correta—ou se você sequer tem uma. Você viu dados desatualizados aparecerem inesperadamente, observou a mesma consulta ao banco de dados disparar várias vezes por requisição e se perguntou por que algumas rotas parecem lentas apesar de serem “estáticas.”

Este artigo explica como o cache de dados do App Router do Next.js realmente funciona, como as três camadas de cache interagem, e como construir componentes de servidor reutilizáveis que encapsulam tanto a busca de dados quanto a política de cache. Também abordaremos o Partial Prerendering do Next.js e como a renderização parcial do React 19 habilita estratégias de cache no nível de componente.

Como as Três Camadas de Cache Funcionam Juntas

O cache do Next.js opera através de três mecanismos distintos que interagem durante cada requisição.

Data Cache

O Data Cache persiste resultados de fetch entre requisições e deployments. Quando você chama fetch com cache habilitado, o Next.js armazena a resposta no lado do servidor. Requisições subsequentes retornam dados em cache até que a revalidação ocorra.

// Em cache por 1 hora em todas as requisições
const posts = await fetch('https://api.example.com/posts', {
  next: { revalidate: 3600 }
})

Full Route Cache

No momento do build, o Next.js renderiza rotas estáticas em HTML e payloads RSC. Este Full Route Cache serve conteúdo pré-renderizado instantaneamente. Rotas puramente dinâmicas ignoram este cache, mas rotas com segmentos estáticos ou revalidação ainda podem gerar shells estáticos.

Client-side Router Cache

O navegador armazena payloads RSC em memória durante a navegação. Layouts persistem entre mudanças de rota. Rotas visitadas são armazenadas em cache na memória durante a sessão e reutilizadas durante a navegação até serem invalidadas.

Essas camadas se cascateiam: invalidar o Data Cache afeta requisições subsequentes, e o Full Route Cache ou Router Cache são atualizados na próxima renderização que requer dados atualizados.

Construindo Componentes de Servidor Reutilizáveis com Cache

O modelo mental que previne bugs de dados desatualizados: componentes devem possuir sua própria política de cache.

// lib/data.ts
import { cache } from 'react'

export const getProduct = cache(async (id: string) => {
  const res = await fetch(`https://api.example.com/products/${id}`, {
    next: { revalidate: 300, tags: ['products', `product-${id}`] }
  })
  return res.json()
})

Esta função pode ser chamada de qualquer componente—layout, página ou filho aninhado. O cache() do React deduplica chamadas dentro de um único passe de renderização. A opção next.revalidate controla o tempo de vida do Data Cache. Tags permitem invalidação cirúrgica.

Use esta função em qualquer lugar sem prop drilling:

// app/products/[id]/page.tsx
export default async function ProductPage({ params }: { params: { id: string } }) {
  const { id } = await params
  const product = await getProduct(id)
  return <ProductDetails product={product} />
}

Moldando o Comportamento do Cache com Opções de Segmento de Rota

Além das opções de fetch, configurações de segmento de rota controlam o cache no nível da rota:

// Força renderização dinâmica
export const dynamic = 'force-dynamic'

// Define período de revalidação para todos os fetches
export const revalidate = 3600

Para invalidação sob demanda, use revalidatePath ou revalidação baseada em tags:

// app/actions.ts
'use server'
import { revalidateTag } from 'next/cache'

export async function updateProduct(id: string) {
  // await db.product.update(...)
  revalidateTag(`product-${id}`)
}

Partial Prerendering do Next.js: A Direção Experimental

O Partial Prerendering do Next.js representa uma mudança significativa. Em vez de escolher entre rotas totalmente estáticas ou totalmente dinâmicas, o PPR pré-renderiza um shell estático enquanto faz streaming de conteúdo dinâmico através de limites de Suspense.

import { Suspense } from 'react'

export default async function ProductPage({ params }: { params: { id: string } }) {
  const { id } = await params
  
  return (
    <>
      {/* Shell estático - pré-renderizado */}
      <Header />
      <ProductInfo id={id} />
      
      {/* Buraco dinâmico - streaming no momento da requisição */}
      <Suspense fallback={<CartSkeleton />}>
        <UserCart />
      </Suspense>
    </>
  )
}

As porções estáticas são servidas instantaneamente. Seções dinâmicas fazem streaming conforme são resolvidas. Este recurso ainda é experimental—habilite-o via ppr: true nas opções experimentais do seu next.config.js—mas aponta para o futuro do cache no Next.js.

React 19 e Cache no Nível de Componente

O comportamento aprimorado do Suspense no React 19 permite estratégias de cache mais granulares. Componentes envolvidos em Suspense podem gerenciar independentemente seu ciclo de vida de dados. Usando as APIs experimentais use cache e cacheLife, você pode fazer cache de subárvores de componentes em vez de páginas inteiras:

import { cacheLife } from 'next/cache'

async function BlogPosts() {
  'use cache'
  cacheLife('hours')
  
  const res = await fetch('https://api.example.com/posts')
  const posts = await res.json()
  return <PostList posts={posts} />
}

A revalidação baseada em tags permite que equipes compartilhem dados em cache com segurança entre rotas. Um componente de produto usado tanto em /products/[id] quanto em /checkout pode ser invalidado uma vez, atualizando em todos os lugares.

Conclusão

Construa componentes de servidor que encapsulam sua política de cache. Use cache() do React para deduplicação de requisições, opções de fetch para controle do Data Cache, e tags para invalidação entre rotas. O Partial Prerendering é experimental, mas vale a pena entender—é para onde o cache do Next.js está caminhando.

O objetivo não é o máximo de cache. É um cache previsível que corresponde aos requisitos reais de atualização dos seus dados.

Perguntas Frequentes

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.