Cache: 'use cache', tag-uri și PPR

Ce este cache-ul

Cache = păstrezi rezultatul unei operații costisitoare (query în DB, request la API, randare) ca să nu o refaci la fiecare cerere. Rezultatul: pagini instantanee și mai puțină încărcare pe server.

Prețul: datele din cache se pot învechi. De aceea orice cache are nevoie de o strategie de invalidare — când arunci copia veche.

Cache Components (Next 16)

Modelul din Next 16, activat în next.config.ts:

const nextConfig = { cacheComponents: true, partialPrefetching: true }

Regula: nimic nu e cache-uit implicit. Tu marchezi explicit ce se cache-uiește, cu directiva 'use cache'.

'use cache'

import { cacheLife, cacheTag } from 'next/cache'

export async function getPosts() {
  'use cache'
  cacheLife('hours')       // cât trăiește
  cacheTag('posts')        // etichetă pentru invalidare
  return db.post.findMany()
}

• Argumentele funcției intră automat în cheia de cache: getPost(1) și getPost(2) sunt intrări separate.
• Se pune pe funcții de date, pe componente sau pe o pagină întreagă.
• Nu poți citi cookies() / headers() înăuntru — le citești afară și trimiți valoarea ca argument.

Profilurile cacheLife

Ce este Partial Prerendering

PPR combină static și dinamic în aceeași pagină:

1. La build, Next randează tot ce poate (inclusiv ce e în 'use cache') → static shell, servit instant de pe CDN.
2. Părțile dinamice (în <Suspense>, care citesc cookies etc.) sunt randate la request și transmise în stream.

Exact aplicația asta: lecția e în static shell; progresul tău (din cookie) vine în stream.

Output-ul npm run build arată tipul fiecărei rute: ○ static, ◐ partial prerender, ƒ dinamic.

Invalidare — tipuri și când

Pe scurt

• Nimic nu e cache-uit implicit; 'use cache' + cacheLife + cacheTag explicit.
• PPR = static shell instant + părți dinamice în stream.
• updateTag pentru userul care tocmai a modificat; revalidateTag(tag, 'max') pentru restul.

Surse oficiale

• Next.js — Caching
• Next.js — Revalidating
• Next.js — use cache
• Next.js — updateTag