O que o Next.js oferece nativamente
- Data cache – No Next.js 13+, cada chamada
fetch()cai em um cache de memória por requisição. Adicionar uma opçãorevalidatediz ao runtime para atualizar os dados após um intervalo definido, transformando uma chamada de API "quente" (hot) em uma "fria" (cold) apenas quando necessário. - Full-route cache – O framework persiste o HTML renderizado e os dados necessários para uma rota inteira. Visitantes recorrentes veem uma transição instantânea porque o servidor pula a renderização novamente.
- ISR – Páginas estáticas são regeneradas em segundo plano enquanto a versão antiga continua servindo o tráfego. Isso permite manter um site grande estático sem a necessidade de um rebuild completo toda vez que o conteúdo muda.
- Server Component
cache()– O helpercachedo React faz a memoização de cálculos caros ou conexões de banco de dados durante a duração de uma única requisição, evitando trabalho duplicado dentro da árvore de componentes de uma página.
Esses caches resolvem o problema do "primeiro acesso" (first-hit), mas ainda vivem dentro do processo Node. Para proteger o servidor e o banco de dados, leve o cache para fora.
Camadas externas que você pode adicionar
| Camada | O que armazena | Ferramenta típica | Como ajuda |
|---|---|---|---|
| CDN | Ativos estáticos, HTML, JSON de API | Cloudflare, Akamai, AWS CloudFront | Move o conteúdo para locais de borda (edge), encurtando o tempo de ida e volta para o usuário |
| Proxy reverso | Respostas de páginas inteiras antes de chegarem ao Node | Nginx, Varnish | Serve páginas em cache diretamente, reduzindo a carga na instância do Next.js |
| Cache em nível de aplicação | Resultados de consultas pesadas ao DB ou chamadas de API | Redis, Memcached | Fornece um armazenamento de chave-valor rápido que sobrevive a reinicializações do servidor e pode ser compartilhado entre múltiplas instâncias do app |
Cada camada fica mais longe do banco de dados de origem, de modo que uma falha de cache (miss) em um nível cascateia para o próximo, atingindo o banco de dados apenas quando absolutamente necessário.
Mantendo os caches atualizados
A invalidação costuma confundir a maioria das equipes. Três padrões práticos funcionam bem:
- Baseado em tempo (TTL) – Atribui uma expiração fixa a uma entrada de cache. Simples de configurar, mas pode servir dados desatualizados até que o temporizador expire.
- Baseado em eventos – Conecte-se ao seu CMS ou a qualquer fonte de dados que emita um webhook quando o conteúdo mudar. O webhook aciona uma limpeza (purge) da entrada de cache relacionada.
- Baseado em tags – Anexe uma tag lógica a um grupo de fetches (ex:
product-list). Quando qualquer item nesse grupo muda, uma única chamada pararevalidateTag('product-list')limpa todas as entradas que compartilham a tag.
Misturar essas abordagens permite equilibrar o frescor dos dados com as taxas de acerto de cache (cache-hit rates).
A hierarquia que funciona para a maioria das equipes
- Cache do navegador – Ativos estáticos (CSS, JS, imagens) recebem um
max-agelongo para que o dispositivo do usuário nunca precise perguntar à rede novamente. - CDN – Nós de borda (edge nodes) fazem o cache de páginas HTML completas e JSON de API, respeitando os cabeçalhos
Cache-Controlque você define no Next.js. - Proxy reverso – Uma instância Nginx ou Varnish fica à frente do servidor Next.js, servindo respostas em cache para rotas que raramente mudam.
- Cache interno do Next.js – Os caches de dados e rotas do framework lidam com a memoização por requisição e o ISR.
- Cache da aplicação – O Redis armazena os resultados de consultas pesadas ao banco de dados, indexados por parâmetros de consulta ou tags.
- Banco de dados – A fonte definitiva da verdade, consultada apenas em caso de falha de cache em todos os níveis superiores.
Quando uma requisição chega, ela percorre esta lista até que uma camada a responda. A resposta mais rápida vence, e a resposta é escrita de volta na cadeia para acessos futuros.
Juntando as peças
- Defina cabeçalhos
Cache-Controlem suas rotas de API - Configure seu CDN – Ative o cache de borda para endpoints HTML e JSON, e certifique-se de que o CDN respeite o
Cache-Control. - Implemente um proxy reverso – Coloque o Nginx à frente do seu servidor Next.js.
- Adicione o Redis – Faça o cache dos resultados de consultas pesadas ao banco de dados.
- Use
revalidateTagem seus componentes – ChamerevalidateTagpara limpar o cache interno do Next.js para uma tag específica.
Resumo
Um único cache dentro do Next.js acelera a primeira requisição, mas a verdadeira escalabilidade vem de uma stack disciplinada: navegador → CDN → proxy reverso → framework → Redis → banco de dados. Configure cada camada, gerencie a invalidação com tempo, eventos e tags, e acompanhe suas métricas. A latência permanece baixa enquanto seu backend sobrevive a picos de tráfego.
