Next.js ISR vs SSG vs on-demand revalidation: Diagramă decizională cu 5 cazuri reale

Postat 13 iun. 2026

typescript

import { NextRequest, NextResponse } from 'next/server';
import { revalidateTag } from 'next/cache';

// Ruta API: /api/revalidate?tag=produse
export async function POST(request: NextRequest) {
  const secret = request.nextUrl.searchParams.get('secret');
  const tag = request.nextUrl.searchParams.get('tag');

  if (secret !== process.env.MY_SECRET_TOKEN) {
    return NextResponse.json({ message: 'Token invalid' }, { status: 401 });
  }

  if (!tag) {
    return NextResponse.json({ message: 'Lipsește tag-ul' }, { status: 400 });
  }

  try {
    revalidateTag(tag);
    return NextResponse.json({ revalidated: true, now: Date.now() });
  } catch (err) {
    return NextResponse.json({ message: 'Eroare la revalidare' }, { status: 500 });
  }
}

Am văzut săptămâna trecută un coleg care genera static 15.000 de pagini de produse la fiecare deploy, doar pentru că se mai schimba stocul din când în când. Haideți să lămurim când folosim SSG, ISR și on-demand revalidation în Next.js App Router, ca să nu mai omorâm serverele de CI/CD degeaba. Am trecut prin asta la un proiect cu peste 12.000 de produse și am redus build time-ul de la 18 minute la sub 2 minute folosind strategia corectă.

SSG pur vs. ISR vs. On-Demand

Dacă randezi totul static la build (SSG), ai cel mai rapid site pentru utilizator, dar ești blocat cu date vechi până la următorul deploy. ISR (Incremental Static Regeneration) îți permite să updatezi paginile în fundal, la un interval de timp (de exemplu, la fiecare 60 de secunde).

On-demand revalidation (prin tag-uri sau path-uri) este însă "sfântul graal": pagina rămâne statică până când sistemul tău (un CMS sau o bază de date) trimite un webhook care zice "hei, s-a schimbat ceva, șterge cache-ul pentru pagina asta".

5 Scenarii reale și decizia corectă

Ca să nu ne mai pierdem în teorie, am adunat mai jos cinci situații clare din producție.

1. Blogul de prezentare (SSG)

Strategia: SSG clasic.
De ce: Articolele se scriu rar. Nu ai nevoie de date în timp real. Un simplu build la deploy sau un revalidate la 24 de ore este mai mult decât suficient pentru a ține costurile jos.

2. Catalogul de produse e-commerce (ISR standard - revalidate: 3600)

Strategia: ISR cu timp generos (1 oră).
De ce: Ai mii de produse. Nu vrei să faci build la toate. Dacă un user vede o descriere modificată acum 10 minute în loc de acum o secundă, nu moare nimeni. Pagina se va regenera în fundal la prima vizită după expirarea orei.

3. Prețul și stocul în e-commerce (On-demand revalidation)

Strategia: revalidateTag('produs-123') declanșat prin webhook din ERP.
De ce: Aici e critic. Dacă vinzi un produs care nu mai e pe stoc, ai pierdut bani și încrederea clientului. Când ERP-ul modifică stocul, trimiți un request rapid către o rută de API din Next.js care curăță cache-ul instantaneu doar pentru acel produs.

4. Dashboard-ul de client / Contul meu (Dynamic Rendering - SSR/CSR)

Strategia: force-dynamic sau fetch cu no-store.
De ce: Datele sunt ultra-specifice pentru fiecare utilizator logat (istoric comenzi, adresă). Nu ai ce să pui în cache global. Aici vrei randare direct pe server la fiecare request sau fetch pe client-side direct din API.

5. Pagina de Termeni și Condiții (Static pur)

Strategia: SSG fără nicio revalidare.
De ce: Se schimbă o dată pe an. Orice request de revalidare rulat aici e doar irosire de resurse.

Trade-off-ul sincer de care se tace

On-demand revalidation sună perfect, dar vine cu o problemă de arhitectură: ai nevoie de o infrastructură care să trimită acele webhook-uri stabil. Dacă API-ul tău de revalidare pică sau webhook-ul din CMS dă timeout, utilizatorii vor vedea date vechi (stale) la nesfârșit.

În plus, dacă folosești un hosting serverless precum Vercel, revalidarea on-demand funcționează brici, dar dacă ești self-hosted pe Docker cu mai multe instanțe în spatele unui load balancer, trebuie să te asiguri că ai un cache shared (cum ar fi Redis), altfel revalidezi doar instanța care a primit request-ul.

Voi cum gestionați cache-ul pe proiectele mari de e-commerce? Mergeți pe ISR la câteva minute sau ați implementat on-demand cu Redis?