Statické, dynamické a hybridní weby
Nejde o to, zda je web statický, nebo dynamický. Rozhoduje, kdy vznikne HTML: při buildu, na serveru, nebo až v prohlížeči.
Tým staví nový obsahový web a zvolí SPA, „protože je to moderní". V prohlížeči všechno vypadá dobře. JavaScript se stáhne, spustí, natáhne data a stránka se poskládá.
Pak přijde crawler. Stáhne první HTML a najde jen prázdný shell. Skutečný obsah čeká za JavaScriptem, který se má teprve spustit. Web je technicky online, uživatel ho při dobrých podmínkách vidí, ale pro vyhledávač je drahé spouštět JavaScript a tak to moc nedělá.
Tři místa, kde vzniká HTML
HTML může vzniknout při buildu, na serveru při požadavku, nebo až v prohlížeči. Každé místo něco zjednoduší a něco prodraží.
Při buildu (SSG, Static Site Generation, takhle to dělá Nua site). HTML se vygeneruje při sestavení webu, uloží jako soubor a doručuje z CDN. Při návštěvě už se nic nepočítá pro konkrétního uživatele. Výsledek je rychlý, levný, odolný a crawler vidí obsah hned. Sedí to na marketing, blog, dokumentaci a další obsah, který je pro všechny stejný a nemění se každou vteřinu.
Na serveru při požadavku (SSR, Server-Side Rendering). HTML se skládá znovu pro příchozí požadavek. Hodí se tam, kde stránka potřebuje čerstvá nebo osobní data: e-shop s aktuální cenou a skladovostí, stránka pro přihlášeného uživatele, obsah závislý na oprávnění. Cena je serverový runtime, latence navíc a nutnost škálovat servery podle návštěvnosti.
V prohlížeči (CSR, Client-Side Rendering). Prohlížeč dostane minimální HTML, stáhne JavaScript, spustí ho, načte data a teprve pak postaví DOM. To je typický svět Single Page Apps. Dává smysl pro dashboardy a vysoce interaktivní aplikace, kde je pomalejší první načtení přijatelná daň za aplikační zážitek a komfort při vývoji - takhle funguje administrace Contemberu. Pro veřejný obsahový web je to riziko, protože nejdůležitější text nevzniká v HTML odpovědi.
Proč čistý CSR škodí veřejnému obsahu
Google dnes JavaScript umí. To ale neznamená, že je dobré nutit vyhledávač, aby kvůli každému článku spouštěl JavaScript.
Googlebot nejdřív stáhne HTTP odpověď a z HTML vytáhne odkazy. Stránky s HTTP 200 pak řadí i do fronty pro renderování, kde je podle dostupných zdrojů vykreslí headless Chromium a z výsledného HTML znovu čte obsah a odkazy. U klasické nebo serverově vykreslené stránky je hlavní obsah v odpovědi hned. U app shellu musí Google čekat na spuštění JavaScriptu. Může to být pár vteřin, ale může to trvat déle; hlavně to není krok, na který má veřejný obsah spoléhat.
Proto čistý CSR bolí tam, kde je organické vyhledávání hlavní zdroj návštěvnosti, kde má obsah hodnotu jen čerstvý, nebo kde důležitý text existuje výhradně až po běhu JavaScriptu. Nejde jen o Google. Ne každý crawler, sociální síť, auditní nástroj nebo interní systém zvládá JavaScript stejně dobře. Detail dopadu na vyhledávání řeší SEO.
Tím padá častý mýtus: „dynamický web je lepší pro SEO." Ne. Pro nalezitelnost je výhoda, když crawler dostane reálné HTML hned. Dynamika pomáhá tehdy, když řeší čerstvost nebo personalizaci; sama o sobě žádný SEO bonus nepřidává.
Hybrid se volí po stránkách, ne pro celý web
Moderní frameworky nenutí vybrat jeden režim pro celý web. Volíte ho pro stránku, šablonu nebo konkrétní cestu (typu všechny články).
Landing page a blog mohou být SSG. Košík může být SSR, protože potřebuje aktuální data. Přihlášený účet může běžet jako CSR aplikace, protože crawler ho stejně neuvidí a uživatel tam čeká interaktivní rozhraní. Kombinujeme to úplně běžně, i některé weby na Nua site už mají CSR vrstvu, která něco obohacuje.
Dva užitečné hybridní vzory
Hybrid je způsob, jak vzít rychlost statiky a doplnit ji jen o tolik dynamiky, kolik stránka potřebuje.
ISR (Incremental Static Regeneration) je vlastně cache. Stránka se vygeneruje při buildu a doručuje jako cachované HTML, ale umí se přegenerovat i po deployi. Buď po nastaveném čase, nebo na vyžádání. Často se používá v nastavení stale-while-revalidate: návštěvník dostane stávající verzi hned a na pozadí se začne renderovat nová. Je to celý super, ale když máte stale-while-revalidate 2 minuty, nechcete vidět ten účet, co dorazí. Je potřeba zvažovat, jak tu cache invalidovat, abyste ji mohli měnit co nejméně často.
Islands architecture řeší jiný problém: JavaScript. Stránka přijde jako hotové HTML a jen vybrané komponenty se v prohlížeči samostatně hydratují jako „ostrovy". Zbytek stránky zůstane statický. Astro to řídí direktivami jako client:idle, client:visible nebo client:media, takže interaktivní část ožije až ve chvíli, kdy ji uživatel pravděpodobně potřebuje. Existují i server islands, kde se dynamický fragment renderuje na serveru odděleně od zbytku statické stránky. Je to super a jedna z moc hezkých věcí na Astro.
Obě věci řeší výkon. Hotové HTML pomáhá LCP, méně JavaScriptu zlepšuje interaktivitu a snižuje riziko posunů layoutu. Dobrý hybrid je zkrátka série dobrých rozhodnutí.
Statické neznamená bez CMS
Častý mýtus, na který teď narážíme je: „statický web nejde editovat, protože nemá CMS." To je samozřejmě nesmysl.
Statické znamená jen to, že HTML vznikne předem při buildu. CMS může běžet úplně normálně. Editor píše, schvaluje a publikuje. Rozdíl je v okamžiku, kdy se změna promítne do HTML: publikace nespustí renderování při návštěvě, ale build, webhook nebo revalidaci dotčené stránky.
Při buildu se rendering potkává s content modelem. Strukturovaná entita, třeba článek s titulkem, autorem a tělem, je vstup. Rendering je krok, který tu entitu mění na HTML.
A protože rendering často běží při buildu, patří i do CI/CD pipeline. U malého webu to je rychlé a netřeba řešit. U velkého obsahu už build může běžet 10+ minut a je dobré se nad tím zamyslet - protože nechcete nasazovat quick fix a čekat 10 minut na nasazení.
Čas build-time u SSG
Proti SSG se často ozve námitka: „na velký nebo často měnící se web to nejde, buildy budou trvat věčnost." Může být, ale není to vlastnost SSG obecně, spíš to může být použitou technologií nebo jejím špatným použitím.
Generátory typu Hugo nebo Astro umí stavět velké množství stránek velmi rychle, protože jsou malé a zkompilované. U webu se stovkami tisíc stránek a častým publikováním ale plný rebuild samozřejmě může být problém. Proto vznikly inkrementální buildy, kdy použitý generátor ví, co musí přegenerovat a přegeneruje pouze to. A i teď, díky AI, jsou časy generování stále rychlejší a rychlejší.
Co tedy zvolit
Pro pětistránkovou vizitku je hybridní aparát zbytečný. Serverový runtime, revalidace, cache invalidace a více režimů selhání nepřidají hodnotu, pokud se celý web mění jednou za měsíc a je pro všechny stejný. Ideální na Nua site (SSG) - jednoduchý build, statický hosting, levný provoz, snadný rollback. CMS pořád existuje, jen publikuje přes build nebo webhook.
Jakmile tam začnou být dynamické detaily - třeba jméno přihlášeného člověka nebo malé doporučení v patičce - pořád to nemusí být důvod renderovat serverově celou stránku. Těch technických možností je více a pokud to jde, SSG je pro hodně webů ta správná cesta.
Rozhodovací rámec
Místo „statický, nebo dynamický?" se ptejte pro každou důležitou stránku čtyři otázky.
- Pro koho je obsah? Pro všechny stejný → SSG. Personalizovaný pro jednotlivého uživatele → SSR nebo klientské načtení dat.
- Jak rychle musí být čerstvý? Zřídka měněný obsah → SSG. Pravidelně aktualizovaný, ale ne real-time → ISR. Data platná jen v okamžiku požadavku → SSR.
- Musí to crawler vidět hned? Ano → SSG, SSR nebo ISR, tedy strategie, která pošle obsah v HTML. Ne, jde o přihlášený dashboard → CSR je v pořádku.
- Co unese provoz? Statický hosting bez runtime → SSG. Serverový nebo edge runtime → SSR, ISR a jemnější hybridní vzory.
Tabulka fit / no-fit
| Strategie | Sedne na | Nesedne na | Kde HTML vzniká |
|---|---|---|---|
| SSG | marketing, blog, dokumentace, obsah stejný pro všechny | personalizace pro jednotlivého uživatele, real-time data | při buildu |
| SSR | e-shop, přihlášené stránky, čerstvá nebo osobní data | neměnný obsah s velkou návštěvností, kde by se jen zbytečně počítalo | na serveru při požadavku |
| CSR / SPA | přihlášené dashboardy, vysoce interaktivní aplikace | veřejný obsah závislý na SEO | v prohlížeči |
| ISR | velký obsahový web, čerstvý ale ne real-time obsah | čistý statický export bez Node.js runtime | build + revalidace |
| Islands | obsah s několika interaktivními prvky, důraz na výkon | aplikace, která je interaktivní celá naskrz | server + dílčí hydratace |
Zdroje
- Hulu (květen–červen 2020) — JS/prerender chyba, Googlebot dostával 404 vs. uživatel 200; 56% propad viditelnosti, 64 % obsahu 404 při crawlu. LinkResearchTools, Bartosz Góralewicz.
- Google Search Central — zpracování JavaScriptu přes crawling, rendering a indexing; renderovací fronta; doporučení pro serverové renderování nebo předrenderování.
- Next.js docs — Incremental Static Regeneration, time-based a on-demand revalidace, stale-while-revalidate, limit Node.js runtime a nepodpora ve static exportu.
- Astro docs / patterns.dev — islands architecture, komponentová hydratace přes
client:*direktivy, server islands. - Hugo, Gatsby, css-tricks — rozdíly v build časech SSG, inkrementální a distribuované buildy. Gatsby blog (leden 2020, „Announcing Gatsby Builds and Reports"): Gatsby Builds přinesl až 60× rychlejší buildy oproti jiným CD řešením; Third and Grove zkrátil build 15 000stránkového webu z 60 na 1 minutu.
- GitHub Pages docs — limit published site 1 GB, soft bandwidth limit 100 GB/měsíc, soft limit 10 buildů/h, bez server runtime.
- Netlify / Wikipedia — Jamstack, Mathias Biilmann, 2015.
Rendering je okamžik, kdy se strukturovaná entita mění na HTML. Je krokem build a deploy pipeline a přímo určuje, jaký hosting a CDN web potřebuje — u Cloudflare třeba volbu mezi statickým hostingem a runtime. Volba mezi hotovým HTML a klientským JavaScriptem rozhoduje o nalezitelnosti i výkonu. Pojmy sjednocuje slovník.