SSR (Server-Side Rendering) polega na generowaniu HTML strony na serwerze, przy każdym zapytaniu, i wysyłaniu go gotowego do wyświetlenia do przeglądarki. W przeciwieństwie do SPA (Single Page Application), która wysyła pustą skorupę JavaScript wymagającą hydratacji w przeglądarce, SSR dostarcza treść indeksowalną i widoczną natychmiast. To historyczny tryb renderingu webu (PHP, Rails, Django) — wrócił po stronie React przez Next.js, Remix lub Nuxt po stronie Vue.
SSR ma dwie duże zalety. SEO: Google czyta HTML bezpośrednio, bez zależności od wykonania JavaScriptu (które jest losowe po stronie Googlebota). Pierwszy paint: użytkownik widzi treść w ~500 ms-1 s, podczas gdy SPA pozostaje biała aż do pełnej hydratacji — to właśnie psuło Core Web Vitals SPA. Wada: każde zapytanie kosztuje CPU serwera, więc skaluje się gorzej niż SSG serwowany z CDN.
Kiedy wybrać SSR zamiast SSG lub ISR? Gdy treść jest personalizowana per użytkownik (dashboard, panel klienta, ceny B2B), gdy dane zmieniają się przy każdym zapytaniu (kursy giełdowe, stan magazynu e-commerce w czasie rzeczywistym) lub gdy wolumen stron jest tak ogromny, że SSG robi się nie do opanowania. Dla większości stron marketingowych preferowane są ISR lub SSG. Z Next.js App Router miksujemy trzy tryby strona po stronie wedle potrzeby. Konkretne przykłady — w naszych stronach na zamówienie.
SSR vs SSG vs ISR: który tryb dla jakiej treści
- [SSG](/glossaire/ssg/): strony statyczne generowane przy buildzie (blog, wizytówka, marketing) — maks. wydajność, minimalny koszt.
- [ISR](/glossaire/isr/): SSG + okresowa rewalidacja (katalog e-commerce, news) — świeżość bez pełnego rebuilda.
- SSR: rendering przy każdym zapytaniu (panel użytkownika, ultraświeże dane, serwerowy A/B test) — maks. elastyczność, koszt CPU.
- Client-side (SPA): do unikania dla stron indeksowalnych — zarezerwowane dla aplikacji po zalogowaniu (dashboardy).
