React
use cache no Next.js: performance e controle
use cache no Next.js salva a resposta da função; com CacheLife você define segundos a semanas — padrão 15 min — e aguenta pico sem derrubar o backend.
ReactNext.js
Carregando
use cache no Next.js salva a resposta da função; com CacheLife você define segundos a semanas — padrão 15 min — e aguenta pico sem derrubar o backend.
use cache no Next.js grava o retorno da função no cache do servidor; com CacheLife você define de segundos a semanas (padrão comum ~15 min) e segura pico sem martelar o backend. Abaixo: quando usar, TTL e armadilhas.
Com uma linha — use cache — você converte qualquer função no Next.js em uma máquina de performance. Basta adicionar <code>"use cache"</code> na função alvo, e pronto: a resposta fica salva e repetidas chamadas não sobrecarregam o servidor. É instantâneo, é fácil, e resolve gargalos comuns em apps modernos.
O cache não é eterno! O padrão são apenas 15 minutos — ou seja, updated e estático ao mesmo tempo. Não confie para sempre: pense no ciclo de vida do seu dado!
Nem sempre 15 minutos são suficientes ou ideais. Por isso, Next.js oferece um controle refinado de quanto tempo o cache vive: da atualização por segundos até ciclos de dias ou semanas . Use a função CacheLife importando de <code>next/cache</code> , ajustando o tempo conforme sua necessidade real — sem reinventar a roda.
Controle total: escolha default (15min), days , hours , minutes , seconds , weeks ou o misterioso max (tempo máximo suportado). Cada cenário, um ajuste.
Imagine seu produto explodir: 1 milhão de pessoas abrindo a mesma página no mesmo segundo. Se não houver cache, seu backend vai ao chão. Mas com cache por segundo , só a primeira requisição acerta o server, as demais pegam o resultado cacheado. Você serve todos com performance máxima e mínimo estresse para infra.
É assim que grandes e-commerces aguentam o tranco de eventos massivos sem explodir custos ou cair fora do ar.
Atualizar preços a cada segundo parece impossível? Errado. Ao cachear a função que retorna o preço por 1 segundo , cada novo segundo traz a informação atualizada, mas sem sobrecarga massiva de acessos idênticos. Resultado: dados sempre frescos e custos sob controle.
O segredo está no equilíbrio: nem tanto ao céu, nem tanto ao inferno. Muitas vezes, 1s de cache resolve tudo que parece impossível de otimizar!
1. Importe CacheLife de <code>next/cache</code> 2. Defina <code>"use cache"</code> no início da função. 3. Passe <code>CacheLife</code> como parâmetro para definir tempo personalizado. Exemplo: para cache de 1 segundo, basta: <code>CacheLife.seconds(1)</code> .
Erros comuns: esquecer de importar CacheLife, typo em diretivas, ou definir tempo muito alto para dados sensíveis.
Sistemas financeiros, previsões, mercados dinâmicos ou e-commerces globais: tarefas em que milhões querem o “dado do momento”, mas não toleram instabilidades. Nessas horas, cachear por segundos entrega equilíbrio entre atualização e performance — e nenhum stack moderno pode viver sem isso.
Dados sigilosos não devem ser cacheados publicamente, nem por 1 segundo! Ajuste sua estratégia conforme o contexto.
Next.js oferece a opção CacheLife.max() para atingir o limite máximo suportado de cache — quando você quer guardar uma resposta pelo maior período possível. Mas cuidado: não abuse! Usar sem critério pode expor dados desatualizados por tempo demais.
Tenha sempre consciência do impacto de suas configurações de cache nas jornadas do usuário e na segurança da informação.
É tentador eliminar o cache para não correr risco de desatualização, mas isso geralmente derruba a performance e aumenta o custo para valores ridículos. Saiba: o cache existe para servir ágil quando todos pedem a mesma coisa ao mesmo tempo.
NUNCA remova todo cache sem um motivo muito forte. Teste, meça e use logs para checar o impacto!
Projetos grandes, picos de tráfego, viralizações: quem não cacheia deixa de atender e perde dinheiro. O cache reduz riscos e permite que você invista menos em infraestrutura para entregar mais valor.
Serviços globais sobrevivem em Black Fridays porque cacheiam de verdade. Pense grande, cacheie melhor.
Quando o dado precisa mesmo ser fresco? Quantas vezes por minuto ele muda realmente? Quantos podem acessar igual, ao mesmo tempo? Essas respostas definem sua estratégia de cache.
Faça perguntas-chave antes de definir seu tempo de cache: experiência, risco, custo e volume.
- Dados estáveis: use cache longo - Dados dinâmicos, mas massivos: cache curto (1-5 segundos) - Dados ultra dinâmicos e individuais: evite cache ou personalize com cautela
Simples, rápido e seguro: escolha seu tempo, meça, otimize sempre.
Cacheie sempre que vários usuários vão acessar o mesmo dado em sequência. Não cacheie informações críticas, privadas ou que mudam a cada usuário.
Nem tudo precisa ser cacheado. Priorize volume e estabilidade, nunca segurança ou personalização individual.
Aprofunde-se no docs oficial do Next.js para entender cenários avançados. Assista ao vídeo completo no canal Dev Doido no <a href="https://www.youtube.com/@DevDoido">YouTube</a> para ver exemplos e dicas extras. Faça testes em projeto real — só assim você domina de verdade!
Quer mais hacks de cache e performance? Tem vídeo completo, dica prática, e muita maluquice útil no canal Dev Doido do YouTube. Não perde!
Implemente e revise sempre sua política de cache. Métricas, logs, e uma boa dose de curiosidade são a chave para evitar grandes problemas — e criar soluções duráveis e escaláveis.
A diretiva "use cache" marca uma função (ou trecho) para o Next.js memoizar o resultado no servidor. Chamadas repetidas reutilizam a resposta cacheada até expirar o tempo de vida configurado.
O padrão típico nos exemplos gira em torno de 15 minutos, mas você deve definir CacheLife explicitamente (segundos a semanas) conforme o frescor do dado — preço de produto não é o mesmo que página institucional.
Não substitui tudo. Continua sendo preciso invalidar ou escolher TTL certo. use cache brilha em funções caras e leituras repetidas; mutações e dados ultra-frescos pedem revalidação explícita ou leitura sem cache.
Evite em dados por usuário altamente personalizados sem chave correta, em escritas, e quando o stale de minutos quebra regra de negócio (estoque crítico, pagamento). Meça hit rate e latência antes de cachear tudo.
Para ir além do cache: curso Next.js completo, SSR/SSG no Next.js, escala com Next.js + Supabase e API REST com Node.js.