export default async function ProductPage({ params }: { params: { id: string } }) {
const res = await fetch(`https://api.exemplu.ro/products/${params.id}`, {
next: { tags: ['products', `product-${params.id}`] }
});
const product = await res.json();
return <div>{product.name} - {product.price} RON</div>;
}
// În API-ul de webhook de la CMS:
// import { revalidateTag } from 'next/cache';
// await revalidateTag(`product-${body.id}`);Recent am lucrat la un magazin online cu vreo 12.000 de SKU-uri unde echipa inițială mersese pe SSG pur, că așa citiseră ei că e cel mai rapid pentru SEO. Da, era rapid pentru user, dar build-ul în CI/CD ajunsese la 22 de minute și orice typo în descrierea unui produs însemna încă 20 de minute de așteptat după pipeline. Ne-am mutat rapid pe ISR și am redus timpul de build la sub 3 minute, generând doar paginile critice la build time. Dacă nu ești atent la cum îți populezi cache-ul, Next.js poate deveni un coșmar de debugging.
SSG (Static Site Generation): Pentru chestii care nu mor
Am folosit SSG pur la un proiect de prezentare pentru o firmă de avocatură. Aveau 10 pagini în total și modificau conținutul o dată la șase luni. Aici SSG e rege. Faci build-ul, urci fișierele pe un CDN și ai terminat povestea. Nu ai nevoie de server, nu ai nevoie de revalidare, costuri zero de hosting pe multe platforme. Problema apare când scrii un blog și ajungi la 500 de articole. Să faci build la 500 de pagini pentru o virgulă schimbată în footer e o risipă enormă de resurse.
ISR (Incremental Static Regeneration): Compromisul necesar
ISR e practic un SSG cu un cron job invizibil. Pui revalidate: 3600 și Next.js știe că după o oră trebuie să verifice dacă a apărut ceva nou. Dar atenție la un aspect pe care mulți îl ignoră: primul user care accesează pagina după ce expiră timpul va vedea tot conținutul vechi. Next.js declanșează regenerarea în spate și abia al doilea user vede update-ul. La un site de știri cu trafic mare, am setat ISR la 60 de secunde. Am economisit cam 80% din load-ul pe baza de date față de SSR-ul clasic, iar userii n-au sesizat că știrea e cu un minut în urmă.
On-Demand Revalidation: Când vrei 'acum'
Aici e unde lucrurile devin interesante în App Router cu revalidateTag și revalidatePath. La proiectul de e-commerce menționat, am renunțat la intervale de timp. Am făcut un webhook în CMS care, atunci când cineva apasă 'Save' pe un produs, trimite un request către Next.js și șterge cache-ul doar pentru acel produs. E mult mai eficient. Totuși, trade-off-ul e complexitatea. Trebuie să ai un sistem solid de tagging. Dacă dai flush la tot cache-ul (revalidatePath('/')) pe un site cu 50k vizitatori simultani, s-ar putea să-ți îngenunchezi baza de date când toți acei useri forțează regenerarea paginilor.
5 Scenarii și decizia optimă
- Blog personal/Documentație: SSG la build time. E simplu și ieftin.
- Site de știri/Revistă: ISR cu un interval de 60-300 secunde. Nu merită efortul de webhooks pentru fiecare știre, un delay de câteva minute e acceptabil.
- E-commerce (Prețuri și Stoc): On-demand revalidation. Nu vrei să vinzi un produs care a ieșit din stoc acum 5 minute doar pentru că ISR-ul tău e setat la o oră.
- Dashboard de utilizator: SSR (Dynamic rendering). Nu ai ce să pui în cache aici, datele sunt private și se schimbă la fiecare click.
- Pagini de Marketing / Landing Pages: SSG + On-demand. Vrei viteză maximă, dar vrei să poți corecta un typo instantaneu.
Personal, am început să prefer tot mai mult revalidateTag în loc de timpi ficși. E mult mai predictibil pentru client. Când apasă butonul de publicare, vrea să vadă schimbarea, nu să stea cu cronometrul în mână. Voi ce folosiți cel mai des pentru a menține cache-ul proaspăt fără să omorâți serverul?