Otázka není jak renderovat, ale kdy
CSR, SSR, SSG, ISR. Zní to jako čtyři soupeřící technologie, mezi kterými se musíš rozhodnout jednou provždy. Nejsou. Jsou to čtyři odpovědi na jedinou otázku: kdy vznikne to HTML, které uživatel dostane. Jakmile tu osu uvidíš, přestaneš je pamatovat jako zkratky a začneš mezi nimi volit podle jednoho parametru — a klidně i stránku od stránky.
Osa má dva konce. Buď HTML vyrobíš předem, jednou pro všechny. Nebo až ve chvíli, kdy o něj někdo požádá. Všechno ostatní jsou body mezi tím.
Čtyři body na téže ose
SSG (build time). HTML vznikne, když nasazuješ. Leží hotové na CDN, request jen sáhne pro soubor. Nejrychlejší TTFB, nejnižší cena serveru, skvělé SEO. Daň: obsah je starý od posledního buildu. U tisíců stránek navíc build trvá.
SSR (request time). HTML se sestaví při každém požadavku. Můžeš do něj dát cokoli osobního — přihlášeného uživatele, košík, data pár milisekund staré. Za to platíš pomalejším TTFB a serverem, který dře u každého requestu.
ISR (build time, ale dodatečně). Kompromis mezi předchozími dvěma. Stránku vyrenderuješ jednou a cachuješ jako u SSG, ale necháš ji po nastaveném intervalu nebo na webhook přegenerovat. Dostaneš skoro rychlost statiky a přitom se obsah obnovuje bez celého rebuildu.
CSR (v prohlížeči). Server pošle skoro prázdný shell a HTML doskládá až JavaScript u klienta. Server nestojí skoro nic, appka je maximálně interaktivní. Daň je nejtvrdší na začátku: první vykreslení čeká na stažení a běh bundlu a vyhledávače to hůř indexují.
Za každý posun něčím platíš
Žádný z těch bodů není lepší. Každý jen přesouvá cenu jinam. Posun k build timu kupuje rychlost a levný provoz za čerstvost dat. Posun k request timu kupuje čerstvost a personalizaci za latenci a cenu serveru. Posun ke klientovi kupuje interaktivitu a nulový server za pomalý start a horší SEO.
Proto se ptej ne „co je nejmodernější", ale jak moc se ten konkrétní obsah mění a pro koho je osobní. Blogový článek nebo dokumentace se nemění mezi requesty a nikoho neidentifikují — patří na build time. Dashboard s tvými daty musí vzniknout až ve chvíli, kdy víš, kdo se dívá. Katalog s tisíci položkami, které se občas změní, je učebnicový případ pro ISR.
Zásadní je, že tuhle volbu neděláš pro celou aplikaci. Moderní frameworky ji nechávají na úrovni stránky, někdy i jednotlivé komponenty přes streaming — statická skořápka se pošle hned a osobní kus se dostreamuje, až doběhne. Osa se tím nemění, jen po ní umístíš každý kus zvlášť.
Co si z toho odnést
Přestaň brát rendering strategie jako tábory, ke kterým se hlásíš. Ber je jako jeden posuvník: kdy vyrobit HTML, od nasazení až po každý request. Každá poloha kupuje jednu vlastnost za jinou a neexistuje mezi nimi vítěz, jen vhodnost pro daný obsah.
Než sáhneš po výchozím nastavení frameworku, polož si u každé stránky dvě otázky: jak často se ten obsah mění a jestli je pro každého jiný. Odpověď tě na té ose posadí skoro sama. A protože se rozhoduje per stránka, nemusíš tou volbou svázat celou appku — statické, čerstvé i osobní části můžou žít vedle sebe.