Co je render budget a proč rozhoduje o SEO i výkonu
Render budget je praktická hranice množství práce, kterou musí vykonat prohlížeč (a robot vyhledávače) k vykreslení použitelné stránky. Jde o kombinaci času, CPU, paměti a přenesených bajtů, které si můžete „dovolit“ využít, abyste dosáhli cílových hodnot Core Web Vitals a zároveň umožnili spolehlivou indexaci obsahu. V prostředí bohatých JS frameworků se rozhodující stává, kde a kdy renderujete: server-side, client-side nebo hybridně s promyšlenou hydratační strategií.
Indexace vs. renderování: dvouvlnový model a důsledky
Vyhledávače typicky procházejí dvěma kroky: fetch & index statického HTML a následná render wave, při které se spouští JavaScript. Pokud klíčový obsah a structured data existují až po klientské hydrataci, riskujete zpožděné pochopení stránky nebo dokonce ztrátu kontextu. Proto jádro obsahu, kanonické odkazy, interní navigační prvky a schémata patří do HTML dodaného ze serveru.
Server-side vs. client-side: rámcový přehled
| Přístup | Popis | Výhody | Rizika / Náklady | Typické použití |
|---|---|---|---|---|
| SSR (Server-Side Rendering) | Server vygeneruje HTML pro každý request | Rychlejší první obsah, robustní indexace, předvídatelnost | Zátěž na server, potřeba cache, následná hydratace JS | Obsahové weby, e-commerce PLP/PDP, blogy, zprávy |
| SSG (Static-Site Generation) | HTML generované při build-time | Skvělá latence, CDN, stabilita | Statický obsah bez revalidace, doby buildů | Dokumentace, marketing, dlouhý ocas obsahu |
| ISR (Incremental Static Regeneration) | Statika s průběžnou revalidací | Vyvážení čerstvosti a výkonu | Složitost cache invalidace | Obsah s periodickými aktualizacemi |
| CSR (Client-Side Rendering) | HTML „shell“, obsah vykreslí JS v prohlížeči | Bohaté interakce, flexibilita | Zpožděné FCP/LCP, riziko indexace, vysoký JS budget | App-like sekce, dashboards, po přihlášení |
| Edge/Streaming SSR | HTML streamováno postupně, často na edge uzlech | Nízký TTFB, časný vykreslovací „skeleton“ | Komplexita infrastruktury a šablonování | Globální publikum, personalizace v měřítku |
Z čeho se skládá render budget
- Síť: TTFB, velikost HTML, CSS, JS, obrázky, fonty, počet požadavků, protokoly (HTTP/2, HTTP/3).
- CPU: parsování, layout, stylování, spouštění JS, hydratace komponent.
- Paměť: velikost DOM, počet nodů, JS heap, obrázky a fonty.
- Interakce: čas do použitelnosti (INP), blokující úlohy, long tasks.
Praktická rovnice pro odhad: Budget_TTI ≈ Cílové_TTI − (TTFB + HTML_parse + CSS_blocking + Hydratace + JS_exec). Vše nad tuto hranici ohrožuje LCP a INP.
Core Web Vitals jako maják: LCP, INP, CLS
- LCP – dominují velké obrázky, hero komponenty a render path k nim; preferujte SSR +
link rel="preload"pro kritická aktiva afetchpriority="high"pro hero obrázek. - INP – ovlivňuje hydratace a JS konkurence na vlákně; rozkládejte interaktivitu (islands, lazy listeners) a eliminujte long tasks > 200 ms.
- CLS – rezervujte místo (aspect-ratio), nenahazujte fonty blokujícím způsobem, vyhýbejte se dynamickým vložkám nad obsahem bez placeholderů.
Hydratační strategie: jak neplýtvat JS rozpočtem
| Strategie | Popis | Kdy použít | Poznámky k SEO & výkonu |
|---|---|---|---|
| Plná hydratace | Hydratují se všechny SSR komponenty | Menší stránky s nízkou interaktivitou | Jednoduché, ale často zbytečně nákladné pro JS |
| On-Demand / Interakčně spouštěná | Hydratace až při interakci (klik, hover) | Formuláře, modaly, akordeony | Výrazně šetří INP, pozor na první „lag“ bez warmup |
| Ve Viewportu | Hydratace až když je komponent viditelný | Spodní sekce, recenze, galerie | Používejte IntersectionObserver; kombinuje se s prahy |
| Částečná (Partial) | Hydratuje se jen interaktivní podstrom | SSR šablona s pár interakcemi | Redukuje JS až o desítky procent bez změny UX |
| Islands Architecture | Každý „ostrov“ je autonomní interaktivní blok | Obsahové weby s lokální interaktivitou | Minimalizuje globální hydrataci, lepší LCP/INP |
| Resumability | Server odešle stav; klient pokračuje bez re-renderu | App-like sekce s častými interakcemi | Radikálně snižuje hydratační overhead, komplexnější runtime |
| Streaming + selektivní hydratace | HTML přichází po částech, hydratace prioritizovaná | Velké stránky, globální publikum | Časný „shell“ pro LCP, interakce se připojují podle priority |
| Server Components | Logika a render na serveru, klient dostává minimum JS | Smíšené UI (statické + interaktivní části) | Podstatné snížení JS bundle, pozor na hranice server/klient |
JS budget a praktické limity
- Minimalizujte JS – cílete na co nejnižší gzip/br brotli rozpočet kritického JS (např. < 150 kB gz pro landingy), zbytek odkládejte.
- Code-splitting a lazy importy – načtěte jen to, co stránka opravdu používá; nepoužívané knihovny odstraňte.
- Polyfill „na požádání“ – vyhněte se globálním polyfillům; používejte feature detection.
- Kontrola třetích stran – mapujte a škálujte skripty (tag manager, A/B testy, chaty); nenahrazujte je před LCP.
Síťové optimalizace: priorita zdrojů a závislosti
rel="preload"pro kritické CSS a hero obrázky;as="style",as="image".fetchprioritypro hero assety (vhodné pro LCP),rel="preconnect"na kritické domény.- HTTP/2 multiplexing a minimalizace požadavků; s HTTP/3 snížení latence při ztrátách paketů.
- Brotli komprese pro textové zdroje; moderní formáty obrázků (AVIF/WebP), správné
sizesasrcset.
Fonty a CLS: neblokujte render
- Využívejte
font-display: swapa lokální hostovanou distribuci fontů. - Subsettujte znakové sady; pro hero text preloadujte s
rel="preload" as="font" type="font/woff2" crossorigin. - Vyhněte se FOIT (Flash of Invisible Text); respektujte rezervované místo, aby nevznikal layout shift.
Strukturovaná data a SEO bezpečnost při hydratačních přístupech
- JSON-LD pro mainEntity a klíčové schémata generujte na serveru (SSR/SSG/ISR) – nečekejte na klienta.
- Kritický text obsahu dodávejte v HTML; lazy inject přes JS používejte pouze pro sekundární prvky.
- Interní odkazy a navigaci renderujte serverově, aby crawleři spolehlivě objevili hlubší obsah.
Edge, cache a revalidace: jak si „koupit“ rozpočet zpět
- CDN cache pro HTML (při SSG/ISR bohatá cache),
stale-while-revalidatepro plynulé aktualizace. - Vrstvené cache: pro API odpovědi (kvóty, backendy), obrázky (Image CDN, on-the-fly transformace).
- Personalizace na edge – early hints, varianty HTML podle geo/segmentu bez blokování streamu.
Vzory implementace podle typu stránky
- Marketingový obsah / blog: SSG nebo ISR, islands pro interaktivní bloky (TOC, formulář), serverová schémata, minimální JS.
- Kategorie a produktové stránky: SSR + streaming; seznamy (PLP) s paginací SSR, filtry hydratované on-demand, obrázky s
loading="lazy"adecoding="async". - Webové aplikace: SSR „shell“, Server Components / resumability, interakce po modulech, agresivní lazy hydratace.
Architektura „islands“ v praxi
- Server doručí úplné HTML s obsahem a odkazy.
- Ostrovům přiřaďte hydration policy: visible, idle, interaction, immediate.
- Pro každý ostrov exportujte minimální klientský modul; sdílený runtime udržujte malý.
- Analytiku a třetí strany načítejte deferred přes
data-cookieconsentbránu.
Měření a monitoring render budgetu
- RUM (Real User Monitoring): LCP, INP, CLS z reálných zařízení, segmentace podle zemí a sítí.
- Lab testy: Lighthouse a WebPageTest s mobilním CPU throttlingem (např. 4×) a 4G sítí.
- JS profilace: identifikace long tasks, mapování hydratace, coverage nepoužitého kódu.
- Server & CDN logy: TTFB, cache hit ratio, revalidace a chybovost.
- Search konzole / crawl statistiky: anomálie v renderu, zvýšené chyby JS během render wave.
Checklist: rozhodovací strom pro výběr strategie
- Je obsah klíčový pro SEO? → SSR/SSG/ISR pro text a schémata.
- Potřebuji bohatou interaktivitu? → Islands / Server Components / Resumability.
- Globální publikum a nízký TTFB? → Edge + streaming SSR, přednačítání kritických assetů.
- Přísný výkonový cíl (LCP < 2,5 s, nízký INP)? → snižte JS budget, odložte hydrataci, minimalizujte třetí strany.
- Často se měnící obsah? → ISR nebo krátká TTL + stale-while-revalidate.
Nejčastější chyby a jejich náprava
- „Empty shell“ v HTML: náprava: SSR jádra a schémata; klient jen dotváří interakce.
- Globální hydratace všeho: náprava: islands, on-demand hydratace, split bundly.
- Preload všeho bez priority: náprava: definujte kritickou render path; méně je více.
- Třetí strany v hlavičce: náprava: defer a brány; načítání po interakci nebo po LCP.
- Nedeterministické layouty: náprava: aspect-ratio, rezervy pro hero, stabilní fonty.
Operační model: jak render budget řídit v týmu
- Definujte KPIs a limity: JS budget, max DOM nodes, cílové LCP/INP, TTFB, velikost HTML/CSS.
- „Performance Gate“ v CI: build selže při překročení limitů; report cache-hit, velikosti bundle, coverage.
- Obsahové zásady: hero obrázky s přesnými rozměry, správné formáty, text serverově.
- Incident management: regrese ve Web Vitals spouští rollback nebo feature flag.
Mini-patterny a mikro-optimalizace
- Skeleton UI streamovaný ze serveru, real-data přicházejí v další části.
- Idle hydration: při
requestIdleCallbacknebo poDOMContentLoadeds časovým limitem. - Event delegation místo množství posluchačů; minimalizujte reflow.
- Pragmatické CSS: kritický CSS inline (v rámci limitu), zbytek
rel="preload" as="style"a
