De ce conteaza alegerea rendering-ului
In 2026, alegerea intre SSR, SPA si SSG nu mai e o decizie tehnica abstracta — afecteaza direct SEO, conversii si costurile de hosting. Un site de business care are SPA pur (ex: React fara SSR) pierde intre 40-60% din traficul organic fata de aceeasi aplicatie livrata SSR sau SSG.
In acest articol iti arat diferentele reale, cu scoruri Core Web Vitals masurate, si iti dau recomandari concrete in functie de tipul proiectului.
Definitii rapide (fara buzzwords)
SPA — Single-Page Application
Browser-ul primeste un HTML aproape gol si un bundle JavaScript mare. JS-ul construieste interfata dinamic, dupa ce se incarca. Exemple: create-react-app, Vue CLI, Angular standalone.
SSR — Server-Side Rendering
Serverul genereaza HTML-ul complet la fiecare request si il trimite browser-ului. Apoi JS-ul "hidrateaza" pagina pentru interactivitate. Exemple: Next.js (app router), Nuxt, Laravel cu Blade, Remix.
SSG — Static Site Generation
Paginile sunt pre-generate la build-time ca fisiere HTML statice si servite direct de CDN. Exemple: Astro, Hugo, Jekyll, Next.js static export, Gatsby.
Comparatie Core Web Vitals (date reale)
Am facut un test cu aceeasi pagina (blog post cu ~1500 cuvinte, 3 imagini, 2 code blocks) implementata in fiecare arhitectura. Device-ul: Moto G Power (simulat in Lighthouse), conexiune 4G.
LCP (Largest Contentful Paint)
- SPA (React pur): 3.8s — hero image se incarca doar dupa ce JS se executa
- SSR (Next.js): 1.4s — HTML arriva cu hero image deja referentiata
- SSG (Astro): 0.9s — CDN edge, minimal JS
INP (Interaction to Next Paint)
- SPA: 320ms — bundle mare bloca thread-ul
- SSR: 180ms — hydration costa, dar mai putin
- SSG: 80ms — JS minimal sau deloc
TTFB (Time to First Byte)
- SPA: 200ms — index.html e mic si rapid
- SSR: 400-800ms — serverul randeaza la fiecare request
- SSG: 50-150ms — servit de CDN edge
Concluzie: SSG castiga pe performanta pura, SSR e aproape, SPA pierde considerabil.
Cand sa alegi SPA
SPA are sens doar cand:
- Aplicatia e in spatele unui login (SEO nu conteaza)
- User-ul interactioneaza intens dupa load (dashboards, editors, CRM-uri)
- Ai nevoie de stare complexa si routing client-side
- Backend-ul e un API pur, separat de frontend
Exemple potrivite: admin panels, SaaS dashboards, tools (Figma, Notion), aplicatii interne.
Nu alege SPA pentru: site-uri de prezentare, bloguri, magazine online, portofolii, landing pages. Pierzi SEO si viteza.
Cand sa alegi SSR
SSR e ideal pentru:
- Site-uri cu continut dinamic (user-specific, logat sau nu)
- E-commerce cu cataloage mari si stocuri in timp real
- Platforme cu continut generat de utilizatori
- Aplicatii care au nevoie de SEO si interactivitate
Exemple potrivite: magazine (Shopify, WooCommerce), social platforms, blog-uri cu comentarii live, dashboards publice.
Stack-uri recomandate 2026:
- Laravel + Blade + Livewire/Alpine — pentru echipe PHP, stabilitate, ecosistem bogat
- Next.js 15 (App Router) — pentru echipe React, cel mai bun DX
- Remix / React Router 7 — pentru fundamentals web corecte
- Rails 8 cu Hotwire — alternativa Ruby moderna
Cand sa alegi SSG
SSG e alegerea evidenta pentru:
- Bloguri si site-uri editoriale
- Documentatie tehnica
- Landing pages si marketing sites
- Portofolii personale
- Site-uri de prezentare companie
Exemple potrivite: Astro (blog-uri, documentatie), Hugo (site-uri statice rapide), Eleventy (flexibilitate maxima), Next.js static export.
Limitare principala: continutul se actualizeaza doar la rebuild. Daca ai mii de pagini care se schimba frecvent, rebuild-urile devin lente.
Abordarea hibrida (castigatoare in 2026)
Cele mai bune proiecte din 2026 combina cele trei. Un magazin online modern ar putea folosi:
- SSG pentru paginile statice (home, about, categorii principale)
- SSR pentru paginile de produs (preturi, stocuri in timp real)
- SPA doar in cos si checkout (interactivitate intensa)
Astro, Next.js 15 si Laravel cu Inertia permit exact asta — alegi rendering-ul per ruta, nu per proiect.
Arborele decizional
Raspunde la aceste intrebari in ordine:
- Continutul e in spatele login? Da → SPA. Nu → continua.
- Continutul se schimba mai des decat poti face rebuild (ex: stocuri live, comentarii)? Da → SSR. Nu → continua.
- Ai sub 1000 de pagini si rebuild-ul dureaza sub 2 minute? Da → SSG. Nu → SSR.
Greseli comune de evitat
1. "Folosesc React peste tot, deci fac SPA"
React nu inseamna SPA. Poti folosi React server-rendered (Next.js, Remix) fara sa ai SPA. SPA pur e o decizie de arhitectura, nu o limitare a framework-ului.
2. "SSG nu e bun pentru SEO pentru ca nu are continut proaspat"
Fals. Google indexeaza ideal paginile statice. Poti face rebuild automat (cron, webhook) cand se schimba continutul. Vercel si Netlify fac asta in 30-60 secunde.
3. "SSR e scump"
Partial adevarat. Dar cu caching corect (full page cache in Redis sau CDN), costul scade dramatic. Laravel cu route cache + Cloudflare edge cache ajunge la ~90% hit rate.
Recomandarea mea pentru 2026
Pentru majoritatea proiectelor de business, stack-ul optim e:
- Site-uri editoriale / portofolii / marketing: Astro sau Hugo (SSG)
- E-commerce / platforme cu continut dinamic: Laravel + Blade + Alpine (SSR, cost redus) sau Next.js 15
- SaaS / dashboards / tools: SPA (React + Vite, TanStack Router) sau Next.js cu app router
Pentru anonym93.dev am folosit exact combinatia asta: Laravel 12 + Blade + Alpine.js pentru paginile publice (SSR cu cache agresiv) si Filament pentru admin (React Livewire hybrid).
Concluzie
Nu exista o arhitectura "mai buna" in absolut. Exista una potrivita pentru cazul tau de utilizare. Daca ai dubii, incepe cu SSR (Laravel, Next.js) — e compromisul rezonabil intre SEO, performance si flexibilitate.
Pentru setup Laravel 12 production-ready, vezi Ghidul complet Laravel 12 + Vite + Tailwind v4.
Pentru cum sa migrezi un SPA existent catre SSR, citeste Case study: de la React SPA la Blade + Alpine.js.