Rendering po stronie serwera – SSR w praktyce

Server side rendering wraca do łask — i to z podwójnym uzasadnieniem. Nie tylko poprawia doświadczenie użytkownika, ale ma bezpośredni wpływ na widoczność w wynikach wyszukiwania. Jeśli budujesz aplikację, która ma rankować w Google, zrozumienie mechaniki SSR i jego związku z SEO to nie opcja, lecz punkt wyjścia do sensownych decyzji architektonicznych.

Jak server side rendering różni się od CSR i dlaczego ma to znaczenie dla SSR SEO

Klasyczne aplikacje SPA (Single Page Application) opierają się na renderowaniu po stronie klienta — przeglądarka pobiera pusty szkielet HTML i dopiero po załadowaniu JavaScriptu buduje widoczną treść. Z perspektywy crawlera Google to potencjalny problem. Googlebot co prawda potrafi wykonywać JavaScript, ale odbywa się to z opóźnieniem, w oddzielnej kolejce, z ograniczeniami zasobów. Strona, której treść pojawia się po dwóch sekundach renderowania po stronie klienta, może być indeksowana z kilkudniowym poślizgiem.

SSR rozwiązuje ten problem u źródła. Serwer generuje kompletny HTML jeszcze przed wysłaniem odpowiedzi do przeglądarki. Gdy crawler przychodzi po stronę, widzi gotową treść — bez konieczności wykonywania żadnego skryptu.

Różnica jest odczuwalna przy kilku konkretnych scenariuszach:

• Nowe strony produktowe w e-commerce indeksują się w ciągu godzin, nie dni, bo Googlebot nie musi czekać na JavaScript.
• Treści o wysokiej rotacji — newsy, recenzje, artykuły — trafiają do indeksu zanim staną się nieaktualne.
• Metatagi Open Graph i Twitter Card są dostępne już w pierwszej odpowiedzi HTTP, co przekłada się na poprawne podglądy linków w mediach społecznościowych.
• Core Web Vitals, szczególnie LCP (Largest Contentful Paint), poprawiają się, bo przeglądarka od razu ma HTML do parsowania.

Różnica między SSR a CSR to nie tylko kwestia techniczna — to decyzja wpływająca na to, czy treść w ogóle dotrze do indeksu Google w rozsądnym czasie.

Jak działa SSR w Next.js — getServerSideProps i renderowanie per request

Next.js to dziś de facto standard dla server side renderingu w ekosystemie React. Mechanika działa następująco: przy każdym żądaniu serwer uruchamia funkcję getServerSideProps, pobiera potrzebne dane (z API, bazy danych, CMS), a następnie przekazuje je jako props do komponentu React, który jest renderowany do HTML przed wysłaniem odpowiedzi.

getServerSideProps — kiedy używać, a kiedy odpuścić

Funkcja getServerSideProps uruchamia się przy każdym żądaniu, co czyni ją odpowiednią do treści, które zmieniają się często lub są spersonalizowane. Strona z aktualnym kursem walut, spersonalizowany dashboard użytkownika, wyniki wyszukiwania zależne od query — to naturalne przypadki użycia.

Dla treści statycznych lub rzadko zmienianych lepszym wyborem jest getStaticProps z opcjonalnym revalidate (ISR — Incremental Static Regeneration). Strona generowana raz i serwowana jako statyczny HTML ładuje się szybciej i odciąża serwer. Decyzja między SSR a ISR powinna opierać się na pytaniu: czy ta strona musi być zawsze świeża, czy wystarczy, że odświeży się co kilka minut?

Hydration i podwójne renderowanie

Specyfika Next.js polega na tym, że HTML generowany na serwerze musi zostać „nawodniony” (hydration) po stronie klienta — React przejmuje kontrolę nad drzewem DOM i podpina handlery zdarzeń. To rozwiązanie eleganckie, ale ma pułapkę: jeśli stan renderowanego komponentu na serwerze różni się od stanu po stronie klienta (np. przez dostęp do window lub różne wyniki dla Date.now()), React zgłosi błąd hydration mismatch. W praktyce oznacza to konieczność ostrożnego pisania komponentów, które mają być renderowane serwerowo.

SSR w Nuxt — nuxt.js jako odpowiedź dla ekosystemu Vue

Nuxt to dla Vue to samo, czym Next.js jest dla React — framework z wbudowanym server side renderingiem, który eliminuje konieczność konfigurowania Webpacka, serwerów Node czy routingu od zera.

Nuxt 3 (oparty o Nitro jako warstwę serwerową i Vite jako bundler) wprowadził kilka istotnych zmian w porównaniu z Nuxt 2. Nowe API composables (useAsyncData, useFetch) działa zarówno po stronie serwera, jak i klienta, automatycznie deduplicując żądania — ten sam fetch nie wykonuje się dwa razy przy hydration. To eleganckie rozwiązanie problemu, który w Next.js wymaga ręcznego zarządzania.

Z punktu widzenia SSR SEO Nuxt oferuje:

• Automatyczne generowanie metatagów przez useHead i useSeoMeta — możliwość ustawienia tytułu, description, og:image wprost w komponencie strony, z gwarancją, że trafi do HTML serwowanego crawlerowi.
• Wbudowaną obsługę sitemap przez moduły (@nuxtjs/sitemap), który generuje mapę strony na podstawie zdefiniowanych tras.
• Tryb hybridowy w Nuxt 3 — możliwość zdefiniowania, które trasy mają być renderowane serwerowo, a które jako statyczny HTML, bez zmiany reszty konfiguracji.

Wybór między Next.js a Nuxt to w praktyce wybór między Reactem a Vue. Oba frameworki rozwiązują problem SSR na podobnym poziomie dojrzałości, oba mają szerokie ekosystemy modułów i aktywne community.

Wpływ SSR na Core Web Vitals i techniczne SEO

Sama indeksowalność to dopiero połowa historii. Google od 2021 roku uwzględnia Core Web Vitals jako czynnik rankingowy, a SSR ma bezpośredni wpływ na dwa z trzech wskaźników.

LCP — Largest Contentful Paint w kontekście SSR

LCP mierzy czas do momentu, gdy największy widoczny element strony (obraz, blok tekstu) zostaje w pełni załadowany. W aplikacjach CSR LCP często przekracza 4 sekundy — przeglądarka musi pobrać HTML, załadować JavaScript, wykonać kod, pobrać dane z API, wyrenderować komponent. Każdy krok to dodatkowe milisekundy.

W SSR przeglądarka dostaje gotowy HTML z pierwszą odpowiedzią. Przy dobrze skonfigurowanym cache’owaniu na CDN czas do pierwszego bajtu (TTFB) może wynosić poniżej 100 ms, a LCP poniżej 2,5 sekundy — próg „dobry” według Google. Trzeba jednak pamiętać, że SSR bez cache’owania może paradoksalnie pogorszyć TTFB, jeśli generowanie strony na serwerze trwa długo (np. przez wolne zapytania do bazy danych).

FID, INP i interaktywność

First Input Delay i jego następca INP (Interaction to Next Paint) mierzą responsywność strony na interakcje użytkownika. SSR sam w sobie ich nie poprawia — interaktywność zależy od ilości JavaScriptu wykonywanego po stronie klienta. Tu pomocne są strategie code splitting, lazy loading komponentów i minimalizacja bundle size. Next.js automatyzuje część z tych optymalizacji, ale rozmiar komponentów i liczba zależności wciąż leży po stronie dewelopera.

Pułapki i ograniczenia SSR, o których warto wiedzieć

SSR nie jest rozwiązaniem bez kosztów. Kilka kwestii, które regularnie pojawiają się przy wdrożeniach produkcyjnych, warto znać zanim architektura zostanie zamrożona.

Generowanie HTML na serwerze przy każdym żądaniu oznacza wyższe zużycie zasobów obliczeniowych w porównaniu z serwowaniem statycznych plików. Przy dużym ruchu może to przekładać się na koszty infrastruktury lub konieczność poziomego skalowania serwerów. ISR i agresywne cache’owanie po stronie CDN łagodzą ten problem, ale wymagają przemyślanej strategii invalidacji cache.

Drugi obszar ryzyka to różnice środowiskowe. Kod działający w Node.js (środowisko serwerowe) nie ma dostępu do window, document ani localStorage. Każdy komponent, który odwołuje się do tych obiektów bez odpowiedniej ochrony (typeof window !== 'undefined'), wywoła błąd przy renderowaniu serwerowym. W praktyce oznacza to konieczność audytu wszystkich zewnętrznych bibliotek — nie każda jest gotowa do SSR.

Czas do interaktywności (TTI) może być w SSR paradoksalnie gorszy niż w CSR dla bardzo złożonych stron. Użytkownik widzi gotową treść, ale nie może z nią wchodzić w interakcję, dopóki hydration się nie zakończy. Efekt „zamrożonej strony” przez pierwsze sekundy po załadowaniu bywa frustrujący, szczególnie na słabszych urządzeniach mobilnych.

Dobra architektura SSR to taka, która łączy renderowanie serwerowe dla kluczowych treści indeksowanych przez Google z lazy loadingiem interaktywnych komponentów po stronie klienta. Nie każdy element strony musi być renderowany serwerowo — formularze, widżety czatu, interaktywne kalkulatory mogą spokojnie ładować się po client-side. Decyzje o granicy między SSR a CSR powinny być podejmowane na poziomie poszczególnych komponentów, nie całej aplikacji.