SSR, CSR, SSG a ISR: skutečný rozdíl
SSG vytváří HTML před requestem, obvykle při buildu. SSR ho vytváří na serveru pro každý request. CSR sestavuje velkou část rozhraní až po spuštění JavaScriptu v prohlížeči. ISR uchovává statický výsledek, ale umožňuje jeho regeneraci po nasazení. [6][9][16]
Důležitější než název strategie je tedy okamžik vzniku HTML, délka cache a množství práce v prohlížeči.
SEO: Google renderuje JavaScript, ale CSR není totéž co prerendering
Google popisuje zpracování JavaScriptu ve třech fázích: crawling, rendering a indexing. Když úvodní HTML neobsahuje skutečný obsah, Web Rendering Service musí spustit JavaScript a stránka vstupuje do renderovací fronty. [1]
Google zároveň doporučuje server-side rendering nebo prerendering, protože zrychlují stránku pro uživatele a crawlery a ne každý bot JavaScript spouští. [1]
CSR může fungovat, ale pro důležitý veřejný obsah je významné HTML v první odpovědi robustnější.
SSG: dobrý výchozí bod pro málo proměnlivý obsah
Při SSG vzniká HTML při buildu a může být servírováno jako statický soubor z CDN. Next.js doporučuje Static Generation, pokud lze stránku připravit před requestem. [9][12]
Landing pages, dokumentace, články, nápověda, portfolio a část produktových katalogů jsou typické případy. [10][16]
Limitem jsou velmi časté změny nebo příliš dlouhé buildy.
SSR: když obsah musí být čerstvý nebo závisí na requestu
SSR vytváří HTML pro konkrétní request a může využít aktuální data, headers, cookies, lokalizaci nebo parametry. [6][10][11]
Pro SEO je obsah ihned v HTML, ale každý request přidává práci serveru a pomalý rendering může zvýšit TTFB. [6]
Stabilní části lze cacheovat.
ISR: statické HTML s řízenou čerstvostí
ISR zachovává výhody statického HTML a umožňuje regeneraci po deployi. Next.js dokumentuje aktualizaci statických stránek po buildu a Nuxt 4 nabízí podobné mechanismy přes `isr` a `swr`. [9][13][16]
Hodí se pro katalogy, články, dokumentaci a kategorie, které se mění periodicky, ale nepotřebují real-time přesnost.
U stale-while-revalidate může první návštěvník po expiraci dostat starší verzi, zatímco nová vzniká na pozadí. [13][16]
CSR: vhodné pro aplikace bez potřeby indexace
Při CSR musí prohlížeč stáhnout, analyzovat a spustit JavaScript, než vytvoří velkou část DOM. web.dev upozorňuje, že velké JavaScript balíky mohou zhoršit INP, hlavně na mobilních zařízeních. [6][7]
Nuxt uvádí SaaS, back-office, hry a další silně interaktivní rozhraní bez SEO požadavků jako vhodné případy. [13]
U veřejného obsahu CSR zvyšuje závislost na JavaScript renderingu crawlerů. [1][2]
Srovnání SEO a výkonu
| Režim | Kdy vzniká HTML | Obsah v počátečním HTML | Čerstvost | Náklady na request | SEO |
|---|---|---|---|---|---|
| SSG | Build | Ano | Do dalšího buildu | Velmi nízké | Velmi dobré |
| ISR | Build nebo revalidace | Ano | Podle revalidace | Nízké | Velmi dobré |
| SSR | Každý request | Ano | Velmi vysoká | Vyšší | Velmi dobré |
| CSR | V prohlížeči | Často omezený | Vysoká po fetchi | Server nízký, klient vyšší | Možné, méně optimální |
Neexistuje univerzální pořadí. SSG a ISR mají často výhodu cache a ceny, SSR výhodu čerstvosti a CSR flexibilitu v prohlížeči. [6][9][13]
Pro SEO mohou SSG, ISR i SSR vrátit významné HTML okamžitě. CSR může Google indexovat, ale vyžaduje další rendering. [1][9]
Core Web Vitals: rendering je jen jedna část
| Metrika | Dobré | Slabé | Co měří |
|---|---|---|---|
| LCP | ≤ 2.5 s | > 4.0 s | Načtení hlavního obsahu |
| INP | ≤ 200 ms | > 500 ms | Odezvu interakcí |
| CLS | ≤ 0.1 | > 0.25 | Vizuální stabilitu |
Google používá Core Web Vitals v rankingových systémech, ale dobré výsledky nezaručují vysokou pozici. Aktuální metriky jsou LCP, INP a CLS. [4][5]
Doporučené dobré hodnoty jsou LCP ≤ 2,5 s, INP ≤ 200 ms a CLS ≤ 0,1 na 75. percentilu. [4][8]
SSG může rychle dodat HTML a přesto mít špatný INP kvůli JavaScriptu. SSR může zlepšit první render, ale pomalý backend zhorší TTFB. [6][7]
Hydratace: SSR nekončí odesláním HTML
Mnoho frameworků hydratuje SSR nebo SSG výstup připojením stavu a event handlerů po doručení HTML. web.dev upozorňuje, že plná rehydration může zvýšit TBT a zhoršit INP. [6]
Stránka může vypadat hotově a přitom krátce nereagovat.
Pomáhá menší JavaScript, code splitting, lazy loading a částečná nebo odložená hydratace. Nuxt 4 dokumentuje téměř statické stránky s minimem JavaScriptu. [7][14]
Cache a čerstvost: klíčový rozdíl
SSG používá výsledek do dalšího buildu. ISR přidává revalidaci. SSR může renderovat každý request, ale může také využít serverovou nebo CDN cache. [6][13][16]
Volba má vycházet z maximálního povoleného stáří dat. Několik minut může být přijatelné u produktu, ale ne u zůstatku účtu.
Invalidace cache by měla pokud možno reagovat na skutečné změny obsahu.
SEO není jen rendering
HTML nenahrazuje správné HTTP statusy, crawlable odkazy, canonical, sitemap, title a metadata. Google doporučuje vlastní URL a crawlable odkazy pro důležitý obsah. [1][2]
Špatně implementované SSR může stále vracet chybné 200, duplicity nebo špatná metadata. Rendering je pouze jedna část technického SEO.
Google nedoporučuje Dynamic Rendering jako dlouhodobé řešení a preferuje SSR, static rendering nebo hydration. [3]
Co zvolit pro různé typy stránek
Landing pages, blogy a dokumentace obvykle sedí na SSG. Velké katalogy nebo periodické novinky na ISR. Veřejné request-dependent stránky mohou potřebovat SSR. Privátní dashboardy mohou zůstat CSR. [9][13]
E-commerce může kombinovat statickou kategorii, ISR pro produkty, SSR pro session data a CSR pro interaktivní filtry.
Rozhodujte po route.
Realita 2026: hybridní modely jsou jemnější
Next.js 16.3.4 dokumentuje Cache Components, `use cache`, revalidaci dat a UI, statickou shell a streaming request-time dat. Aktuální dokumentace cache byla aktualizována 25. srpna 2026. [11]
Nuxt 4 umožňuje `prerender`, `ssr`, `swr` a `isr` po route přes Route Rules. [13][14]
Čtyři pojmy zůstávají užitečné, ale už nepopisují každou moderní komponentu přesně.
Jak zlepšit CSR pro SEO bez velkého rewrite
Nejprve určete veřejné route, které mají skutečně získávat organickou návštěvnost. Privátní dashboard není nutné měnit na SSR jen kvůli jednotnosti.
Potom přesuňte kritický obsah, title, metadata a odkazy do HTML generovaného před klientským JavaScriptem. Google doporučuje SSR nebo prerendering místo Dynamic Rendering. [1][3]
Nakonec ověřte Search Console, renderované HTML a field data Core Web Vitals.
Praktické pravidlo volby
Pokud lze stránku připravit předem a obsah je pro všechny stejný, začněte SSG. Pokud se mění periodicky, zvažte ISR. Pokud výsledek závisí na requestu a má být v HTML, použijte SSR. Pro privátní aplikaci bez SEO cíle často stačí CSR. [9][13]
Poté ověřte TTFB, LCP, INP, CLS, serverové náklady, frekvenci změn, počet stránek a personalizaci.
- Musí být hlavní obsah indexován?
- Lze HTML vytvořit před requestem?
- Jak čerstvá musí být data?
- Závisí výsledek na cookies, session nebo requestu?
- Kolik route se musí generovat?
- Lze stránku bezpečně cacheovat?
- Kolik JavaScriptu musí prohlížeč spustit?
- Jaké jsou reálné LCP, INP, CLS a TTFB v produkci?
