SSR, CSR, SSG i ISR: czym faktycznie się różnią
SSG generuje HTML przed wejściem użytkownika na stronę, najczęściej w czasie builda. SSR generuje HTML na serwerze w momencie żądania. CSR wysyła do przeglądarki niewiele gotowej treści i buduje interfejs po wykonaniu JavaScriptu. ISR zachowuje statyczny charakter strony, ale pozwala regenerować ją po wdrożeniu na podstawie czasu lub jawnego unieważnienia cache. [6][9][16]
Najważniejsze jest więc nie samo hasło `SSR` lub `SSG`, ale odpowiedź na trzy pytania: kiedy powstaje HTML, jak długo jest przechowywany oraz ile pracy musi później wykonać przeglądarka.
SEO: Google potrafi renderować JavaScript, ale to nie znaczy, że CSR jest równoważny prerenderingowi
Google opisuje przetwarzanie stron JavaScriptowych jako trzy etapy: crawling, rendering i indexing. Jeśli początkowa odpowiedź HTML nie zawiera właściwej treści, Google musi uruchomić JavaScript w Web Rendering Service, a strona trafia do kolejki renderowania. [1]
Google podkreśla jednocześnie, że server-side rendering lub prerendering nadal jest dobrym rozwiązaniem, ponieważ przyspiesza stronę dla użytkowników i crawlerów, a nie wszystkie boty potrafią wykonywać JavaScript. [1]
Wniosek praktyczny jest prosty: CSR może działać w Google, ale dla treści, które mają być szybko i niezawodnie indeksowane, gotowy HTML w odpowiedzi pozostaje bezpieczniejszym rozwiązaniem.
SSG: najlepszy punkt startowy dla treści, które nie muszą być świeże na każde żądanie
W SSG HTML powstaje w czasie builda i może być następnie serwowany jako statyczny plik z CDN. Next.js opisuje Static Generation jako generowanie HTML przed żądaniem użytkownika i rekomenduje je tam, gdzie stronę można przygotować z wyprzedzeniem. [9][12]
Typowe zastosowania to landing page, dokumentacja, artykuły, strony pomocy, portfolio i część katalogów produktowych. Statyczny plik nie wymaga wykonania logiki serwerowej przy każdym wejściu, co ogranicza koszt infrastruktury i upraszcza cache. [10][16]
Ograniczeniem jest świeżość. Jeśli dane zmieniają się często albo liczba stron powoduje bardzo długi build, czyste SSG może przestać być praktyczne.
SSR: gdy treść musi być świeża lub zależy od bieżącego żądania
SSR generuje HTML na serwerze dla konkretnego żądania. Dzięki temu można uwzględnić świeże dane, nagłówki, cookies, lokalizację, parametry zapytania albo inną informację dostępną dopiero podczas requestu. [6][10][11]
Zaletą dla SEO jest gotowy HTML bez konieczności czekania na wykonanie klientowego JavaScriptu. Kosztem jest praca serwera przy każdym żądaniu i potencjalnie wyższy TTFB, jeśli renderowanie lub pobieranie danych trwa długo. web.dev wskazuje ten kompromis wprost. [6]
SSR nie oznacza, że cała strona powinna być dynamiczna. Często lepiej cache'ować stabilne fragmenty i renderować dynamicznie tylko to, co rzeczywiście zależy od requestu.
ISR: statyczny HTML z kontrolowaną świeżością
ISR pozwala zachować korzyści statycznego HTML, a jednocześnie odświeżać wybrane strony po wdrożeniu bez pełnego rebuilda. Next.js opisuje ISR jako mechanizm aktualizacji statycznych stron po buildzie, a Nuxt 4 umożliwia podobne zachowanie per route przez `isr` lub `swr`. [9][13][16]
W praktyce ISR dobrze pasuje do katalogów produktów, artykułów, dokumentacji, stron kategorii i innych publicznych treści, które zmieniają się co jakiś czas, ale nie muszą być absolutnie świeże na każde żądanie.
Trzeba zrozumieć semantykę cache konkretnej platformy. Przy modelu stale-while-revalidate pierwszy użytkownik po wygaśnięciu może zobaczyć poprzednią wersję, podczas gdy nowa jest generowana w tle. [13][16]
CSR: najlepszy dla aplikacji, których nie trzeba indeksować
W CSR przeglądarka pobiera JavaScript, parsuje go, wykonuje i dopiero wtedy buduje znaczną część DOM. web.dev wskazuje, że rosnące pakiety JavaScript mogą pogarszać responsywność i INP, szczególnie na urządzeniach mobilnych. [6][7]
Nuxt wskazuje typowe przypadki CSR: aplikacje SaaS, back-office, gry i mocno interaktywne interfejsy, które nie wymagają indeksowania. [13]
Dla publicznego contentu CSR zwiększa zależność od poprawnego wykonania JavaScriptu przez crawlery. Google radzi testować takie strony i nadal rekomenduje prerendering lub SSR, gdy jest to możliwe. [1][2]
Porównanie SEO i wydajności
| Tryb | Kiedy powstaje HTML | Treść w początkowym HTML | Świeżość | Koszt przy requestach | SEO |
|---|---|---|---|---|---|
| SSG | Build time | Tak | Do kolejnego builda | Bardzo niski | Bardzo dobre |
| ISR | Build lub po rewalidacji | Tak | Zależna od rewalidacji | Niski | Bardzo dobre |
| SSR | Każde żądanie | Tak | Bardzo wysoka | Wyższy | Bardzo dobre |
| CSR | W przeglądarce | Często niewielka | Wysoka po fetchu | Niski serwerowo, wyższy po stronie klienta | Możliwe, ale mniej optymalne |
Nie istnieje jedna kolejność `SSG > ISR > SSR > CSR` dla każdego projektu. SSG i ISR mają zwykle przewagę kosztową i cache'ową dla treści wspólnych dla wszystkich. SSR wygrywa świeżością i możliwością reakcji na request. CSR daje największą swobodę aplikacyjną po stronie klienta, ale przenosi większą część kosztu renderowania do przeglądarki. [6][9][13]
Dla SEO SSG, ISR i SSR mogą dostarczyć kompletny HTML już w odpowiedzi. CSR może zostać zindeksowany przez Google, ale wymaga dodatkowego etapu renderowania i jest bardziej zależny od JavaScriptu. [1][9]
Core Web Vitals: tryb renderowania to tylko jedna część układanki
| Metryka | Dobry wynik | Słaby wynik | Co mierzy |
|---|---|---|---|
| LCP | ≤ 2.5 s | > 4.0 s | Szybkość załadowania głównej treści |
| INP | ≤ 200 ms | > 500 ms | Responsywność interakcji |
| CLS | ≤ 0.1 | > 0.25 | Stabilność układu |
Google używa Core Web Vitals jako jednego z elementów systemów rankingowych, ale podkreśla, że dobre wyniki nie gwarantują wysokiej pozycji. Aktualne metryki to LCP, INP i CLS. [4][5]
Za dobry wynik uznaje się LCP do 2,5 s, INP do 200 ms i CLS do 0,1, oceniane na 75. percentylu wizyt. [4][8]
SSG może poprawić czas dostarczenia HTML, ale nadal można zepsuć INP dużą ilością JavaScriptu. SSR może poprawić FCP, ale wolny backend może podnieść TTFB. CSR może działać szybko po rozgrzaniu cache przeglądarki, ale pierwszy widok musi ponieść koszt pobrania i wykonania kodu. [6][7]
Hydracja: SSR nie kończy pracy po wysłaniu HTML
Wiele frameworków po SSR lub SSG uruchamia hydrację, czyli dołącza logikę aplikacji i obsługę zdarzeń do HTML dostarczonego przez serwer. web.dev zwraca uwagę, że pełna rehydracja może pogorszyć TBT i INP, mimo że pierwszy content pojawia się szybko. [6]
To ważne, bo strona może wyglądać na gotową, a jednocześnie przez chwilę nie reagować na interakcje. Sama obecność SSR nie gwarantuje więc dobrej wydajności interakcyjnej.
W praktyce warto ograniczać JavaScript, używać code splitting, lazy loading i częściowej lub opóźnionej hydracji tam, gdzie framework na to pozwala. Nuxt 4 opisuje nawet warianty stron prawie statycznych z minimalnym JavaScriptem. [7][14]
Cache i świeżość danych: kluczowa różnica między SSG, ISR i SSR
SSG zakłada, że gotowy wynik może być używany wielokrotnie do kolejnego builda. ISR dodaje do tego rewalidację. SSR może generować nową odpowiedź na każde żądanie, ale może też być połączony z cache po stronie serwera lub CDN. [6][13][16]
Dlatego decyzja powinna wynikać z maksymalnego dopuszczalnego wieku danych. Jeżeli cena produktu może być opóźniona o kilka minut, ISR bywa dobrym wyborem. Jeśli użytkownik musi zobaczyć stan konta dokładnie w tej chwili, statyczny cache całej strony jest zwykle niewłaściwy.
Najlepszy model cache powinien być powiązany z realną zmianą danych, a nie z arbitralnym krótkim TTL ustawionym tylko po to, by strona wydawała się świeża.
SEO nie kończy się na renderowaniu
Gotowy HTML pomaga crawlerowi zobaczyć treść, ale nie zastępuje poprawnych statusów HTTP, linków, canonicali, sitemap, tytułów i metadanych. Google zaleca, aby każda ważna treść miała własny URL i była dostępna przez crawlable link. [1][2]
SSR wykonane źle może nadal generować 200 dla błędu, brak canonicala, duplikaty albo nieprawidłowe metadane. Z kolei dobrze zbudowany CSR może zostać poprawnie zindeksowany przez Google. Renderowanie jest więc jednym z elementów SEO technicznego, a nie jego substytutem.
Google nie rekomenduje obecnie dynamic rendering jako docelowego rozwiązania dla problemów JavaScript SEO. Zaleca SSR, static rendering albo hydration zamiast osobnej wersji dla botów. [3]
Co wybrać dla konkretnych typów stron
Landing page, blog, dokumentacja i strony informacyjne zwykle dobrze pasują do SSG. Duży katalog produktów albo newsy, które zmieniają się okresowo, często lepiej pasują do ISR. Publiczne strony z danymi zależnymi od requestu mogą wymagać SSR. Panele konta i wewnętrzne aplikacje mogą pozostać CSR. [9][13]
W e-commerce jedna aplikacja może używać kilku modeli równocześnie: statyczna strona kategorii, ISR dla karty produktu, SSR dla koszyka zależnego od sesji i CSR dla interaktywnych filtrów po załadowaniu strony.
Wybór należy wykonywać per route, a w nowoczesnych frameworkach często także per fragment UI.
Realia 2026: frameworki odchodzą od jednej etykiety dla całej strony
Next.js 16.3.4 dokumentuje Cache Components, `use cache`, rewalidację danych i UI, statyczną powłokę oraz streaming danych, które muszą zostać pobrane w czasie requestu. Dokumentacja została zaktualizowana 25 sierpnia 2026. [11]
Nuxt 4 pozwala definiować `prerender`, `ssr`, `swr` i `isr` w Route Rules dla różnych tras. Oznacza to, że ten sam serwis może być częściowo statyczny, częściowo rewalidowany i częściowo renderowany po stronie klienta. [13][14]
Dlatego SSR, CSR, SSG i ISR pozostają dobrym modelem mentalnym, ale nie opisują już dokładnie każdej nowoczesnej aplikacji komponent po komponencie.
Jak migrować aplikację CSR pod SEO bez przebudowy wszystkiego
Najpierw należy wskazać publiczne trasy, które faktycznie mają generować ruch organiczny. Nie ma sensu przenosić do SSR prywatnego dashboardu tylko po to, aby cała aplikacja miała jeden model renderowania.
Następnie warto przenieść krytyczną treść, tytuły, metadane i linki do HTML generowanego przed uruchomieniem JavaScriptu, a pozostałą interaktywność pozostawić klientową. Google sugeruje SSR lub prerendering jako lepsze rozwiązanie niż dynamic rendering dla stron zależnych od JavaScriptu. [1][3]
Na końcu trzeba sprawdzić wynik w Search Console, narzędziach testujących wyrenderowany HTML oraz w danych terenowych Core Web Vitals, bo sama zmiana architektury nie gwarantuje poprawy.
Praktyczna reguła wyboru
Jeżeli stronę można wygenerować wcześniej i content jest wspólny dla wszystkich, zacznij od SSG. Jeżeli treść zmienia się okresowo, rozważ ISR. Jeżeli wynik musi zależeć od konkretnego requestu i ma być dostępny w HTML, użyj SSR. Jeżeli strona jest prywatną aplikacją i SEO nie ma znaczenia, CSR jest często wystarczający. [9][13]
Następnie zweryfikuj decyzję za pomocą rzeczywistych danych: TTFB, LCP, INP, CLS, kosztu serwera, częstotliwości zmian treści, liczby stron i wymagań dotyczących personalizacji.
- Czy najważniejsza treść musi być indeksowana?
- Czy HTML może zostać wygenerowany przed żądaniem?
- Jak świeże muszą być dane?
- Czy wynik zależy od cookies, sesji lub requestu?
- Ile tras trzeba wygenerować i jak długo trwa build?
- Czy strona może być bezpiecznie cache'owana?
- Ile JavaScriptu musi wykonać przeglądarka?
- Jakie są rzeczywiste LCP, INP, CLS i TTFB na produkcji?
