Server-Side Rendering

Cum funcționează SSR

Într-o arhitectură Server-Side Rendering, serverul generează HTML-ul paginii ca răspuns la navigarea utilizatorului. Browserul primește astfel un document care conține deja cea mai mare parte sau întregul conținut necesar afișării inițiale.

Procesarea datelor și aplicarea șabloanelor au loc înainte ca răspunsul să ajungă în browser. Acest lucru poate evita cereri suplimentare necesare pentru construirea inițială a paginii pe dispozitivul utilizatorului. JavaScript poate fi trimis ulterior pentru funcții interactive și logică executată în browser.

Când scripturile adaugă stare și interactivitate peste HTML-ul generat pe server, procesul este numit „hydration”. SSR nu elimină automat JavaScript și nici munca efectuată ulterior în browser.

SSR comparativ cu CSR și randarea statică

În Client-Side Rendering (CSR), aplicația rulează în browser și folosește JavaScript pentru a modifica DOM-ul și a genera conținutul. Motoarele de căutare importante pot executa JavaScript, deci paginile bazate exclusiv pe CSR pot fi indexate. Totuși, SSR permite crawlerelor să citească mai ușor conținutul fără executarea scripturilor.

SSR nu trebuie confundat cu randarea statică. În SSR, HTML-ul dinamic poate fi generat la cerere pentru fiecare URL. În randarea statică, fișierele HTML sunt produse în avans, în etapa de build, și pot fi livrate direct printr-un CDN.

Compromisuri de performanță

SSR produce în general un FCP rapid și poate reduce volumul de JavaScript propriu trimis browserului. Pe de altă parte, generarea paginii pe server necesită timp și poate crește TTFB. Dacă browserul primește apoi mult JavaScript sau efectuează procesări complexe, pagina poate avea în continuare probleme privind TBT și INP. Alegerea trebuie făcută în funcție de conținutul și interactivitatea fiecărei pagini.

Impactul asupra SEO clasic

SSR face conținutul disponibil direct în răspunsul HTML. Astfel, crawlerul poate citi textul și legăturile fără să depindă de executarea JavaScript. Acest lucru simplifică accesarea conținutului, deși nu garantează indexarea sau poziționarea în SERP.

Motoarele de căutare importante pot procesa JavaScript, iar un site CSR poate fi indexat. SSR nu este, prin urmare, o cerință universală pentru SEO. Devine relevant când informația principală apare doar după rularea scripturilor, când există dependențe succesive de date sau când JavaScript eșuează.

SSR poate susține afișarea mai rapidă a conținutului printr-un FCP bun și poate reduce blocarea firului principal dacă limitează JavaScript-ul trimis clientului. Implementarea poate însă crește TTFB, iar hidratarea complexă poate menține valori ridicate pentru TBT și INP.

Accesarea de către alte sisteme automate

Pentru sistemele care citesc răspunsul HTML fără să execute JavaScript, SSR poate face informația principală disponibilă direct. Acest lucru reduce dependența accesării conținutului de randarea în browser, dar nu garantează folosirea sau citarea informației în răspunsurile generate de alte servicii.

SSR trebuie tratat ca o decizie tehnică de accesibilitate și randare. Conținutul principal trebuie să rămână clar și prezent în răspunsul HTML, iar funcțiile esențiale nu ar trebui să depindă inutil de JavaScript.

Un magazin online românesc are pagini de categorie generate dinamic. Când un utilizator sau un crawler solicită categoria „Încălțăminte din piele”, serverul preia datele și trimite un document HTML care include titlul, descrierea, produsele și legăturile către paginile acestora.

JavaScript este folosit ulterior pentru filtre și alte interacțiuni. Dacă scripturile nu rulează, conținutul principal și legăturile rămân prezente în HTML. Aceasta este o implementare SSR combinată cu funcționalitate executată în browser.

1. Deschide pagina în Chrome DevTools și accesează fila Network.
2. Reîncarcă pagina și selectează cererea principală de tip document.
3. Verifică secțiunea Response. Titlul, textul principal și legăturile trebuie să apară în HTML-ul primit, nu doar în DOM după executarea JavaScript.
4. Dezactivează JavaScript din setările browserului și reîncarcă pagina. Verifică dacă informația principală rămâne vizibilă și utilizabilă.
5. Compară răspunsul HTML cu DOM-ul final din fila Elements. Diferențele ample pot indica faptul că o parte importantă a conținutului este adăugată în browser.
6. Analizează în Network volumul și ordinea fișierelor JavaScript necesare înainte ca pagina să devină interactivă.
7. Verifică separat tipurile importante de pagini, deoarece aceeași aplicație poate folosi SSR pentru unele rute și CSR pentru altele.

• Include conținutul principal și legăturile importante în răspunsul HTML generat pe server.
• Folosește JavaScript pentru interactivitate, fără să condiționezi inutil accesul la informația esențială.
• Evaluează SSR separat pentru fiecare tip de pagină; aceeași metodă nu trebuie aplicată obligatoriu întregului site.
• Limitează procesarea efectuată în browser după primirea HTML-ului.
• Monitorizează FCP, TTFB, TBT și INP pentru a identifica efectele arhitecturii alese.
• Diferențiază clar SSR de randarea statică, care generează fișierele HTML în etapa de build.