Resursa

SSR vs ISR vs SSG în Next.js: cum alegi corect

Decizii practice pentru viteză, date fresh și cost.

Problema reală

Mulți aleg SSR “ca să fie sigur”. Apoi se plâng că site-ul e lent și costă mult. Alții fac SSG peste tot și se miră că datele sunt vechi. Alegerea corectă e simplă dacă pornești de la două întrebări:

  1. Cât de des se schimbă conținutul?
  2. Cât de personalizat e per utilizator?

Definiții rapide

  • SSG: pagina se generează la build. Super rapid, super stabil.
  • ISR: ca SSG, dar se regenerează periodic (sau la cerere).
  • SSR: se generează la fiecare request. Fresh, dar mai lent.
  • CSR: randare în browser. Bun pentru zone interactive, slab pentru SEO dacă abuzezi.

Matrice de decizie

Alege SSG când:

  • pagini de prezentare (Home, servicii, despre)
  • landing pages care nu se schimbă zilnic
  • pagini statice cu SEO important
    Beneficii: viteză maximă, cost minim.

Alege ISR când:

  • blog/resurse
  • pagini produs cu schimbări moderate
  • pagini categorie cu update-uri periodice
    Beneficii: viteză aproape ca SSG, date relativ fresh.

Alege SSR când:

  • conținut foarte dinamic și “live”
  • personalizare per user (cont, prețuri B2B)
  • pagini dependente de cookies/auth
    Cost: mai lent, mai scump, ai nevoie de caching inteligent.

Exemple reale (eCommerce)

SSG: servicii, studii de caz, resurse, pagini legale
ISR: categorii, produse (în funcție de business), blog
SSR/CSR: coș, checkout, cont utilizator, dashboard admin

Greșeli comune

  • SSR peste tot → TTFB slab, cost ridicat
  • SSG peste tot → conținut stale
  • CSR peste tot → SEO slab, loading continuu

Rețeta simplă pentru B2B

  • Marketing pages: SSG
  • Resurse/blog: ISR
  • Aplicație/portal: SSR + caching, CSR doar pentru zone autentificate

Checklist final

  • Pagini publice: SSG/ISR
  • Pagini cu date schimbătoare: ISR cu revalidate
  • Zone autentificate: SSR/CSR
  • Cache gândit înainte, nu după ce e lent