SSR, CSR, SSG a ISR: skutočný rozdiel
SSG vytvára HTML pred requestom, zvyčajne pri builde. SSR ho vytvára na serveri pre každý request. CSR zostavuje veľkú časť rozhrania až po spustení JavaScriptu v prehliadači. ISR uchováva statický výsledok, ale umožňuje jeho regeneráciu po nasadení. [6][9][16]
Dôležitejšie než názov stratégie je teda to, kedy HTML vzniká, ako dlho zostáva v cache a koľko práce ostáva pre prehliadač.
SEO: Google renderuje JavaScript, ale CSR nie je to isté ako prerendering
Google opisuje spracovanie JavaScriptu v troch fázach: crawling, rendering a indexing. Ak úvodné HTML neobsahuje skutočný obsah, Web Rendering Service musí spustiť JavaScript a stránka vstupuje do renderovacej fronty. [1]
Google zároveň odporúča server-side rendering alebo prerendering, pretože zrýchľujú stránku pre používateľov a crawlery a nie každý bot spúšťa JavaScript. [1]
CSR môže fungovať, ale pre dôležitý verejný obsah je významné HTML v prvej odpovedi robustnejšie.
SSG: dobrý východiskový bod pre málo premenlivý obsah
Pri SSG vzniká HTML pri builde a môže byť servírované ako statický súbor z CDN. Next.js odporúča Static Generation, ak možno stránku pripraviť pred requestom. [9][12]
Landing pages, dokumentácia, články, nápoveda, portfóliá a časť produktových katalógov sú typické prípady. [10][16]
Limitom sú veľmi časté zmeny alebo príliš dlhé buildy.
SSR: keď obsah musí byť čerstvý alebo závisí od requestu
SSR vytvára HTML pre konkrétny request a môže využiť aktuálne dáta, headers, cookies, lokalizáciu alebo parametre. [6][10][11]
Pre SEO je obsah ihneď v HTML, ale každý request pridáva prácu servera a pomalý rendering môže zvýšiť TTFB. [6]
Stabilné časti možno cacheovať.
ISR: statické HTML s riadenou čerstvosťou
ISR zachováva výhody statického HTML a umožňuje regeneráciu po deployi. Next.js dokumentuje aktualizáciu statických stránok po builde a Nuxt 4 ponúka podobné mechanizmy cez `isr` a `swr`. [9][13][16]
Hodí sa pre katalógy, články, dokumentáciu a kategórie, ktoré sa menia periodicky, ale nepotrebujú real-time presnosť.
Pri stale-while-revalidate môže prvý návštevník po expirácii dostať staršiu verziu, zatiaľ čo nová vzniká na pozadí. [13][16]
CSR: vhodné pre aplikácie bez potreby indexácie
Pri CSR musí prehliadač stiahnuť, analyzovať a spustiť JavaScript, než vytvorí veľkú časť DOM. web.dev upozorňuje, že veľké JavaScript balíky môžu zhoršiť INP, najmä na mobilných zariadeniach. [6][7]
Nuxt uvádza SaaS, back-office, hry a ďalšie silno interaktívne rozhrania bez SEO požiadaviek ako vhodné prípady. [13]
Pri verejnom obsahu CSR zvyšuje závislosť od JavaScript renderingu crawlerov. [1][2]
Porovnanie SEO a výkonu
| Režim | Kedy vzniká HTML | Obsah v počiatočnom HTML | Čerstvosť | Náklady na request | SEO |
|---|---|---|---|---|---|
| SSG | Build | Áno | Do ďalšieho buildu | Veľmi nízke | Veľmi dobré |
| ISR | Build alebo revalidácia | Áno | Podľa revalidácie | Nízke | Veľmi dobré |
| SSR | Každý request | Áno | Veľmi vysoká | Vyššie | Veľmi dobré |
| CSR | V prehliadači | Často obmedzený | Vysoká po fetchi | Server nízky, klient vyšší | Možné, menej optimálne |
Neexistuje univerzálne poradie. SSG a ISR majú často výhodu cache a ceny, SSR výhodu čerstvosti a CSR flexibilitu v prehliadači. [6][9][13]
Pre SEO môžu SSG, ISR aj SSR vrátiť významné HTML okamžite. CSR môže Google indexovať, ale vyžaduje ďalší rendering. [1][9]
Core Web Vitals: rendering je iba jedna časť
| Metrika | Dobré | Slabé | Čo meria |
|---|---|---|---|
| LCP | ≤ 2.5 s | > 4.0 s | Načítanie hlavného obsahu |
| INP | ≤ 200 ms | > 500 ms | Odozvu interakcií |
| CLS | ≤ 0.1 | > 0.25 | Vizuálnu stabilitu |
Google používa Core Web Vitals v rankingových systémoch, ale dobré výsledky nezaručujú vysokú pozíciu. Aktuálne metriky sú LCP, INP a CLS. [4][5]
Odporúčané dobré hodnoty sú LCP ≤ 2,5 s, INP ≤ 200 ms a CLS ≤ 0,1 na 75. percentile. [4][8]
SSG môže rýchlo dodať HTML a napriek tomu mať slabý INP kvôli JavaScriptu. SSR môže zlepšiť prvý render, ale pomalý backend zhorší TTFB. [6][7]
Hydratácia: SSR nekončí odoslaním HTML
Mnohé frameworky hydratujú SSR alebo SSG výstup pripojením stavu a event handlerov po doručení HTML. web.dev upozorňuje, že plná rehydration môže zvýšiť TBT a zhoršiť INP. [6]
Stránka môže vyzerať hotová a pritom krátko nereagovať.
Pomáha menší JavaScript, code splitting, lazy loading a čiastočná alebo odložená hydratácia. Nuxt 4 dokumentuje takmer statické stránky s minimom JavaScriptu. [7][14]
Cache a čerstvosť: kľúčový rozdiel
SSG používa výsledok do ďalšieho buildu. ISR pridáva revalidáciu. SSR môže renderovať každý request, ale môže tiež využívať serverovú alebo CDN cache. [6][13][16]
Voľba má vychádzať z maximálneho povoleného veku dát. Niekoľko minút môže byť prijateľných pri produkte, ale nie pri stave účtu.
Invalidácia cache by mala, ak je to možné, reagovať na skutočné zmeny obsahu.
SEO nie je iba rendering
HTML nenahrádza správne HTTP statusy, crawlable odkazy, canonical, sitemap, title a metadata. Google odporúča vlastné URL a crawlable odkazy pre dôležitý obsah. [1][2]
Zle implementované SSR môže stále vracať chybné 200, duplicity alebo zlé metadata. Rendering je iba jedna časť technického SEO.
Google neodporúča Dynamic Rendering ako dlhodobé riešenie a preferuje SSR, static rendering alebo hydration. [3]
Čo zvoliť pre rôzne typy stránok
Landing pages, blogy a dokumentácia zvyčajne sedia na SSG. Veľké katalógy alebo periodické novinky na ISR. Verejné request-dependent stránky môžu potrebovať SSR. Privátne dashboardy môžu zostať CSR. [9][13]
E-commerce môže kombinovať statickú kategóriu, ISR pre produkty, SSR pre session dáta a CSR pre interaktívne filtre.
Rozhodujte po route.
Realita 2026: hybridné modely sú jemnejšie
Next.js 16.3.4 dokumentuje Cache Components, `use cache`, revalidáciu dát a UI, statickú shell a streaming request-time dát. Aktuálna dokumentácia cache bola aktualizovaná 25. augusta 2026. [11]
Nuxt 4 umožňuje `prerender`, `ssr`, `swr` a `isr` po route cez Route Rules. [13][14]
Štyri pojmy zostávajú užitočné, ale už neopisujú každú modernú komponentu presne.
Ako zlepšiť CSR pre SEO bez veľkého rewrite
Najprv určte verejné route, ktoré majú skutočne získavať organickú návštevnosť. Privátny dashboard netreba meniť na SSR len kvôli jednotnosti.
Potom presuňte kritický obsah, title, metadata a odkazy do HTML generovaného pred klientskym JavaScriptom. Google odporúča SSR alebo prerendering namiesto Dynamic Rendering. [1][3]
Nakoniec overte Search Console, renderované HTML a field data Core Web Vitals.
Praktické pravidlo voľby
Ak možno stránku pripraviť vopred a obsah je pre všetkých rovnaký, začnite SSG. Ak sa mení periodicky, zvážte ISR. Ak výsledok závisí od requestu a má byť v HTML, použite SSR. Pre privátnu aplikáciu bez SEO cieľa často stačí CSR. [9][13]
Potom overte TTFB, LCP, INP, CLS, serverové náklady, frekvenciu zmien, počet stránok a personalizáciu.
- Musí byť hlavný obsah indexovaný?
- Možno HTML vytvoriť pred requestom?
- Ako čerstvé musia byť dáta?
- Závisí výsledok od cookies, session alebo requestu?
- Koľko route sa musí generovať?
- Možno stránku bezpečne cacheovať?
- Koľko JavaScriptu musí prehliadač spustiť?
- Aké sú reálne LCP, INP, CLS a TTFB v produkcii?
