Postavili ste aplikáciu. Potrebovali ste web

Otvorte si posledné tri weby, na ktorých ste pracovali. Zobrazte si zdrojový kód – to, čo pošle server, nie panel Elements – a nájdite prvú vetu, ktorú si návštevník naozaj prečíta.

Aspoň na jednom z nich ju nenájdete. Nájdete len prázdnu kostru, koreňový div a kopu skriptov.

Takéto weby mávajú ešte jeden príznak. Úprava jedného odseku trvá tri týždne.

Za takým webom býva headless CMS a frontend na JS frameworku. Bez vývojára, pull requestu a nasadenia nemôže nikto z marketingu publikovať ani vetu.

Dva príznaky, jedna príčina.

Web nie je rozbitý. Je prekomplikovaný. A platíte za to trikrát – stroje ho neprečítajú, používatelia naň čakajú a váš tím ho už sám nezmení.

Stroje stratili trpezlivosť skôr než používatelia

O renderingu JavaScriptu sme sa desať rokov dohadovali a zakaždým dospeli k rovnakému záveru: Google si s ním poradí, takže pokojne nasaďte SPA.

Ten argument už neplatí.

Vercel spolu s MERJ zmeral, ako sa AI crawlery naozaj správajú. GPTBot aj ClaudeBot si JavaScriptové súbory stiahnu. Ani jeden z nich však žiadny nespustí.

Stiahnuť neznamená vyrenderovať. Načítajú HTML tak, ako príde zo servera, vezmú si, čo v ňom je, a idú ďalej.

Žiadna druhá šanca. A na rozdiel od Googlebota sa k stránke zajtra nevrátia.

Stránka tak môže v Googli držať druhú pozíciu, a pritom byť prázdnym divom pre každý AI vyhľadávač, ktorý nestojí na infraštruktúre Googlu alebo Bingu.

Debata o renderingu sa vždy točila okolo jedného crawlera. Ten však prestal byť jediný, na ktorom záleží.

Platíte v kilobajtoch

Toľko k strojom. Platia aj ľudia.

Obsahová stránka zo statického generátora neposiela takmer žiadny JavaScript. Tá istá stránka na metaframeworku nad Reactom posiela najprv runtime, router a všetko potrebné na hydratáciu. Zhruba 80 až 100 KB po gzipe – len aby sa zobrazil text, ktorý v HTML už bol.

Za rendering toho istého odseku ste zaplatili dvakrát.

Pri objednávkovom procese alebo dashboarde za tú cenu niečo dostanete. Pri blogu, dokumentácii alebo stránke kategórie nedostanete nič.

Tretí účet chodí každý týždeň

Posledný účet uvidíte v kalendári.

Frontend na JS frameworku a headless CMS znamenajú, že každá zmena obsahu ide cez nasadenie. Oprava v cenníku čaká na vývojára. Landing page čaká na sprint.

Kto má texty na starosti, nemôže ich sám publikovať.

Stránky sa tak prestanú opravovať. Nie že by to niekto rozhodol – malá úprava jednoducho stojí viac, ako prinesie.

A pod tým všetkým leží strom závislostí. Treba ich aktualizovať, major verzie niečo rozbijú a správy o zraniteľnostiach na vašu roadmapu čakať nebudú. Prezentačný web na dva roky starom Node stacku má známe zraniteľnosti v balíčkoch, ktoré si nikto nevybral. Natiahol ich tam slider, až v tretej úrovni stromu.

Bezpečnostné záplaty sa prestanú dostávať do produkcie z rovnakého dôvodu ako opravy preklepov. Každá zmena znamená nasadenie.

Hugo a Eleventy, nie to, čo je práve v móde

Platíte trikrát, riešenie je jedno. Ak je stránka dokument, vygenerujte ju pri builde a posielajte hotové HTML.

Astro vedie vo väčšine porovnaní frameworkov a dáva zmysel, ak váš tím chce na obsahových stránkach komponenty v Reacte. Väčšina obsahových stránok však žiadne komponenty nepotrebuje.

Hugo vygeneruje desaťtisíc stránok za pár sekúnd. Celé je to jedna binárka v Go, nepotrebuje Node a nemáte žiadny npm strom, o ktorý by ste sa museli päť rokov starať. Daňou za to sú šablóny v Go.

Eleventy je voľba pre tím, ktorý je doma v JavaScripte. Pri veľkých weboch je pomalší, zato sa v ňom ľahšie vyznáte. V predvolenom nastavení navyše neposiela žiadny klientsky framework.

A Reactu sa kvôli tomu vzdávať nemusíte. Vďaka JSX pluginu váš tím píše komponenty ako zvyčajne, Eleventy ich pri builde vyrenderuje do HTML a do prehliadača sa z nich nedostane nič.

Hugo ani Eleventy nie sú žiadna novinka. Zmenilo sa len to, ako rýchlo ich rozbehnete: na čo kedysi padol víkend nad šablónami a konfiguráciou, to dnes s AI asistentom zvládnete za popoludnie.

So statickým výstupom máte základ istý. V produkcii nič nebeží – žiadna databáza, žiadny plugin, ktorý by ste museli o polnoci záplatovať, žiadny serverový kód, ktorý by sa dal zneužiť. Závislosti, ktoré zostanú, sú len v builde, nie na verejnom internete.

Doriešte hosting a obrázky – a máte z veľkej časti hotovo.

Má to dva háčiky

Next.js vám v predvolenom nastavení väčšinu z toho nedá. Statický export síce prinesie HTML vyrenderované na serveri a vyrieši tým problém s crawlermi, runtime Reactu ani hydratáciu však neodstráni. Viditeľnosť ste vyriešili, váhu ste si nechali. Stále počúvam „je to statické, sme na Nexte“, akoby to bolo jedno a to isté.

Nič nezabráni tomu, aby sa web znova nafúkol. Ľahká statická stránka s tag managerom, cookie lištou, chatovým widgetom a tromi meracími skriptmi bude rovnako pomalá ako všetko ostatné. Generátor rozhoduje o tom, čo nasadíte, nie o tom, čo tam neskôr pridá marketing.

Čo by som použil ja

Väčšina ľudí, ktorí sa pýtajú, aký framework zvoliť, by mala namiesto toho vyberať platformu.

To, čo nasleduje, je moja voľba, nie pravidlo. Správna odpoveď závisí od tímu a od toho, čo firma predáva. Po toľkých auditoch však stále dokola vidím tých istých pár prípadov.

Malý alebo stredne veľký e-shop? Shopify. Postará sa o to, o čo sa starať nechcete – platby, sklad, pokladňu – a jeho šablóny si v Core Web Vitals vedú lepšie než väčšina vlastných riešení. Do headless prestavby sa nepúšťajte, pokiaľ nemáte tím, ktorý ju bude päť rokov prevádzkovať.

Veľa publikujete a redaktori pracujú bez vývojárov? WordPress. Nie je v móde, a predsa je to správna voľba – len majte čo najmenej pluginov a poriadne nastavte cache.

Všetko ostatné? Hugo alebo Eleventy. Marketingové weby, dokumentácia, produktové stránky, programatický obsah – vygenerujte ich a JavaScriptu pošlite do prehliadača len minimum. To je väčšina webov a väčšina toho, čo býva prekomplikované.

Naozaj staviate aplikáciu? Tak stavajte aplikáciu. Next.js je stavaný na objednávkové procesy, dashboardy a všetko za prihlásením – a v tom je dobrý. Chybou nie je, že ho používate. Chybou je, keď na ňom postavíte blog.

A ak prestavba neprichádza do úvahy – čo platí pre väčšinu enterprise webov – renderujte na serveri alebo staticky generujte aspoň šablóny s produktmi a cenami. Interaktívne časti nechajte v prehliadači. Všetci potom dostanú rovnaké HTML.

Čiastočná oprava šablón, ktoré zarábajú, je lepšia než kompletná prestavba, ktorú nikto neschváli.

Najprv si položte tri otázky

Nájdete dôležitý obsah v HTML, ktoré príde zo servera? Potrebuje niečo na stránke stav v prehliadači, ktorý prežije aj ďalšie načítanie? Môže niekto, kto nepíše kód, publikovať zmenu ešte dnes?

Väčšina tímov nevie na prvú otázku odpovedať bez toho, aby si to najprv overila. To samo osebe ukazuje, ako málo z toho bolo vôbec vedomé rozhodnutie.

Desať rokov sme z webov robili aplikácie. Používatelia dostali pomalšie stránky. Stroje dostali stránky, ktoré neprečítajú. A tí, ktorí majú obsah na starosti, ho už nemôžu meniť.

Prekomplikovaný je každý web, ktorý bez prehliadača nepovie, čo na ňom je. A platíte za to trikrát.