Next.js ISR vs SSG vs On-Demand: Cum alegi corect (5 cazuri din producție)

Răzvan Matei · 2026-05-26T04:50:43.855Z

Cum am redus build time-ul de la 45 la 3 minute folosind on-demand revalidation în Next.js. Ghid practic de decizie pentru bloguri, e-commerce și dashboard-uri.

Postat 26 mai 2026

typescript

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

// Endpoint apelat de CMS/ERP când se modifică un produs
export async function POST(request: NextRequest) {
  const secret = request.nextUrl.searchParams.get('secret');
  
  if (secret !== process.env.REVALIDATION_TOKEN) {
    return NextResponse.json({ message: 'Unauthorized' }, { status: 401 });
  }

  const productId = request.nextUrl.searchParams.get('id');
  if (!productId) {
    return NextResponse.json({ message: 'Missing product ID' }, { status: 400 });
  }

  // Curățăm cache-ul doar pentru produsul modificat
  revalidateTag(`product-${productId}`);

  return NextResponse.json({ revalidated: true, now: Date.now() });
}

Salut. M-am lovit recent de o discuție aprinsă cu un client care voia un magazin online cu 12.000 de produse. Voia ca totul să se încarce instant, dar prețurile și stocurile să fie mereu la secundă. Clasica problemă unde mulți juniori sar direct pe SSR (Server-Side Rendering) pur, iar apoi se miră de ce baza de date ia foc la campaniile de marketing și factura de hosting sare în aer.

În Next.js (mai ales în App Router), decizia între SSG, ISR de tip time-based și on-demand revalidation îți poate salva nopțile. Am trecut prin toate trei și am învățat pe pielea mea ce funcționează și ce e doar marketing de la Vercel.

Uite cum pun eu problema acum, bazat pe 5 cazuri reale pe care le-am implementat.

1. Blogul de prezentare (SSG clasic)

Dacă ai un blog cu 50 de articole care se schimbă o dată pe săptămână, nu te complica. SSG (Static Site Generation) la build-time este sfânt.

Cum funcționează: Folosești fetch cu cache-ul implicit, adică cache: 'force-cache'.
Trade-off: Orice virgulă modificată cere un rebuild în CI/CD. La 50 de pagini, build-ul durează un minut, deci e perfect acceptabil și extrem de ieftin de găzduit.

2. Landing page-uri de marketing (ISR la timp)

Aici ai content editori care modifică chestii în headless CMS. Nu vrei să rulezi build-ul la fiecare literă corectată, dar nici nu ai nevoie de update instant.

Soluția: ISR cu timp fix. Configurezi revalidate = 3600 (o oră) la nivel de pagină sau direct în fetch.
Trade-off: Primul utilizator care intră după ce expiră ora va declanșa regenerarea în fundal, dar el tot va vedea pagina veche (stale). Al doilea va vedea pagina nouă. E un compromis excelent pentru 90% din site-urile de prezentare.

3. Pagina de produs în E-commerce (On-demand revalidation)

Aici e durerea. Dacă vinzi adidași și stocul scade de la 1 la 0, nu poți aștepta o oră să se propage modificarea. Dar nici nu vrei SSR la fiecare vizită, că pierzi viteza de încărcare.

Soluția: On-demand revalidation folosind tag-uri de cache. Când se schimbă stocul în ERP, trimiți un webhook către Next.js și cureți cache-ul doar pentru acel produs folosind revalidateTag.
Trade-off: E cel mai performant sistem, dar crește complexitatea. Trebuie să gestionezi securitatea webhook-ului și să te asiguri că ERP-ul chiar trimite acel apel corect.

4. Dashboard-ul de utilizator (SSR sau Client-side)

Am văzut echipe încercând să facă ISR pe pagini de profil sau setări cont. Nu face asta. Datele private, specifice fiecărui user, nu au ce căuta în cache-ul shared de pe edge servers.

Soluția: Dezactivezi complet cache-ul folosind force-dynamic sau faci fetch direct de pe client (cu React Query sau SWR).
Trade-off: Pierzi avantajul vitezei de pe edge, dar securitatea și corectitudinea datelor sunt pe primul loc.

5. Pagini de listare cu filtre complexe (Hibrid ISR + Client)

Când ai mii de combinații de filtre (mărime, culoare, preț), este imposibil să le generezi static pe toate la build.

Soluția: Pagina de bază (fără filtre active) este generată static (ISR) ca să se încarce instant de pe CDN. În momentul în care userul bifează un filtru, interfața trece pe fetch-uri client-side.
Trade-off: Ai SEO excelent pe pagina principală de categorie și interactivitate rapidă pe filtre, fără să încarci serverul inutil.

La proiectul de e-commerce menționat, trecerea de la SSG chior (care ne ducea build time-ul la 45 de minute) la un hibrid de ISR cu on-demand revalidation ne-a redus build-time-ul la sub 3 minute și am economisit cam 30% la factura de server.

Voi ce folosiți cel mai des în App Router? Vă bazați pe revalidatePath sau mergeți direct pe revalidateTag pentru control granular?