Randare: server, client, static și streaming

În Next.js, alegerea strategiei de randare determină direct performanța aplicației și experiența utilizatorului final. Într-un mediu profesional, nu există o soluție universală; decizia se bazează pe natura datelor (statice vs. dinamice) și pe cerințele de SEO. Înțelegerea diferenței dintre server-side rendering (SSR), client-side rendering (CSR) și generarea statică (SSG) este crucială pentru a optimiza viteza de încărcare și costurile de infrastructură.

Concepte cheie

• Static Site Generation (SSG): Paginile sunt generate la build-time și servite ca fișiere HTML statice, oferind cea mai rapidă viteză de încărcare și beneficii maxime de SEO.
• Server-Side Rendering (SSR): HTML-ul este generat la fiecare cerere HTTP pe server, permițând afișarea de date actualizate în timp real, dar cu un cost mai mare de latenta.
• Client-Side Rendering (CSR): Browserul descarcă o pagină goală și JavaScript-ul generează conținutul ulterior, ideal pentru dashboard-uri private unde SEO-ul nu contează.
• Incremental Static Regeneration (ISR): Permite actualizarea paginilor statice după build-time fără a reconstrui întregul site, combinând avantajele SSG cu flexibilitatea datelor dinamice.
• Streaming: Tehnica de a trimite fragmente de HTML către browser pe măsură ce sunt pregătite, îmbunătățind percepția vitezei de încărcare prin afișarea progresivă a interfeței.
• Data Fetching: Mecanismele getStaticProps (pentru SSG/ISR) și getServerSideProps (pentru SSR) care preiau datele necesare înainte de randare.

Exemplu practic

Să comparăm două componente pentru o pagină de produs:

// 1. SSG - Pentru produse care se schimbă rar
export async function getStaticProps() {
  const product = await fetchProduct();
  return { props: { product }, revalidate: 60 }; // ISR: revalidează la fiecare 60s
}

// 2. SSR - Pentru prețuri în timp real sau stocuri
export async function getServerSideProps() {
  const stock = await checkRealTimeStock();
  return { props: { stock } };
}

În practică, vei folosi SSG pentru bloguri sau catalogul principal de produse, iar SSR doar pentru secțiuni care necesită date critice la momentul cererii, cum ar fi checkout-ul sau profilul utilizatorului autentificat.

Greșeli frecvente

• Abuzul de SSR: Generarea server-side pentru fiecare pagină când datele nu se schimbă des duce la latență inutilă și costuri mari de server.
• Ignorarea SEO-ului în CSR: Randarea exclusiv pe client face ca motoarele de căutare să nu indexeze corect conținutul, afectând vizibilitatea organică.
• Securitate expusă: Extragerea datelor sensibile (chei API, token-uri) în getStaticProps le expune în codul sursă al clientului dacă nu sunt filtrate corect.

Întrebări de interviu

Când ai alege ISR în locul SSG? Când ai un volum mare de conținut static care se actualizează rar, dar nu poți permite un rebuild complet al site-ului la fiecare modificare.

Care este diferența principală între SSR și CSR din perspectiva UX? SSR oferă First Contentful Paint (FCP) mai rapid pentru utilizatorii noi, în timp ce CSR poate întârzia prima randare până la încărcarea pachetului JS.

Cum gestionezi datele autentificate în Next.js? Datele utilizatorului autentificat se obțin de obicei în getServerSideProps sau prin Server Components, evitând expunerea lor în codul clientului.

Exercițiu

Creează o pagină Next.js care afișează o listă de articole de știri. Folosește getStaticProps pentru a prelua datele simulat și activează ISR cu o valoare de revalidate de 10 secunde. Adaugă un buton care forțează o revalidare manuală a paginii și observă cum se actualizează conținutul fără refresh complet al paginii.