Postavili jste aplikaci. Potřebovali jste web

Otevřete si poslední tři weby, na kterých jste pracovali. Zobrazte si zdrojový kód – to, co vrátí server, ne panel Elements – a najděte první větu, kterou si návštěvník opravdu přečte.

Aspoň na jednom z nich ji nenajdete. Najdete jen prázdnou kostru, kořenový div a hromadu skriptů.

Takové weby mívají ještě jeden příznak. Úprava jednoho odstavce trvá tři týdny.

Za takovým webem bývá headless CMS a frontend na JS frameworku. Bez vývojáře, pull requestu a nasazení nemůže nikdo z marketingu publikovat ani větu.

Dva příznaky, jedna příčina.

Web není rozbitý. Je překomplikovaný. A platíte za to třikrát – stroje ho nepřečtou, uživatelé na něj čekají a váš tým ho už sám nezmění.

Stroje ztratily trpělivost dřív než uživatelé

O renderingu JavaScriptu jsme se deset let dohadovali a pokaždé došli ke stejnému závěru: Google si s ním poradí, takže klidně nasaďte SPA.

Ten argument už neplatí.

Vercel společně s MERJ změřil, jak se AI crawlery doopravdy chovají. GPTBot i ClaudeBot si JavaScriptové soubory stáhnou. Ani jeden z nich ale žádný nespustí.

Stáhnout neznamená vyrenderovat. Načtou HTML tak, jak přijde ze serveru, vezmou si, co v něm je, a jdou dál.

Žádná druhá šance. A na rozdíl od Googlebota se ke stránce zítra nevrátí.

Stránka tak může v Googlu držet druhou pozici, a přitom být prázdným divem pro každý AI vyhledávač, který nestojí na infrastruktuře Googlu nebo Bingu.

Debata o renderingu se vždycky točila kolem jednoho crawleru. Ten ale přestal být jediný, na kterém záleží.

Platíte v kilobajtech

Tolik ke strojům. Platí i lidé.

Obsahová stránka ze statického generátoru neposílá skoro žádný JavaScript. Stejná stránka na metaframeworku nad Reactem posílá nejdřív runtime, router a všechno potřebné pro hydrataci. Zhruba 80 až 100 KB po gzipu – jen aby se zobrazil text, který v HTML už byl.

Za rendering téhož odstavce jste zaplatili dvakrát.

U objednávkového procesu nebo dashboardu za tu cenu něco dostanete. U blogu, dokumentace nebo stránky kategorie nedostanete nic.

Třetí účet chodí každý týden

Poslední účet uvidíte v kalendáři.

Frontend na JS frameworku a headless CMS znamenají, že každá změna obsahu jde přes nasazení. Oprava v ceníku čeká na vývojáře. Landing page čeká na sprint.

Kdo má texty na starosti, nemůže je sám publikovat.

Stránky se tak přestanou opravovat. Ne že by to někdo rozhodl – malá úprava prostě stojí víc, než přinese.

A pod tím vším leží strom závislostí. Je potřeba ho průběžně aktualizovat, major verze něco rozbijí a bezpečnostní upozornění na vaši roadmapu čekat nebudou. Prezentační web na dva roky starém Node stacku má známé zranitelnosti v balíčcích, které si nikdo nevybral. Natáhl je tam slider, až ve třetí úrovni stromu.

Bezpečnostní záplaty přestanou chodit do produkce ze stejného důvodu jako opravy překlepů. Každá změna znamená nasazení.

Hugo a Eleventy, ne to, co je zrovna v módě

Platíte třikrát, řešení je jedno. Pokud je stránka dokument, vygenerujte ji při buildu a posílejte hotové HTML.

Astro vede ve většině srovnání frameworků a dává smysl, pokud váš tým chce na obsahových stránkách komponenty v Reactu. Většina obsahových stránek ale žádné komponenty nepotřebuje.

Hugo vygeneruje deset tisíc stránek za pár sekund. Celé je to jedna binárka v Go, nepotřebuje Node a nemáte žádný npm strom, o který byste se museli pět let starat. Daní za to jsou šablony v Go.

Eleventy je volba pro tým, který dělá hlavně v JavaScriptu. U velkých webů je pomalejší, zato se v něm snáz vyznáte. Ve výchozím nastavení navíc neposílá žádný klientský framework.

A Reactu se kvůli tomu vzdávat nemusíte. Díky JSX pluginu váš tým píše komponenty jako obvykle, Eleventy je při buildu vyrenderuje do HTML a do prohlížeče se z nich nedostane nic.

Hugo ani Eleventy nejsou žádná novinka. Změnilo se jen to, jak rychle je rozjedete: na co dřív padl víkend nad šablonami a konfigurací, to dnes s AI asistentem zvládnete za odpoledne.

Se statickým výstupem máte základ jistý. V produkci nic neběží – žádná databáze, žádný plugin, který byste museli o půlnoci záplatovat, žádný serverový kód, který by šel zneužít. Závislosti, které zůstanou, jsou jen v buildu, ne na veřejném internetu.

Dořešte hosting a obrázky – a máte z velké části hotovo.

Má to dva háčky

Next.js vám ve výchozím nastavení většinu z toho nedá. Statický export sice přinese HTML vyrenderované na serveru a vyřeší tím problém s crawlery, runtime Reactu ani hydrataci ale neodstraní. Viditelnost jste vyřešili, váhu jste si nechali. Pořád slýchám „je to statické, jsme na Nextu“, jako by to bylo jedno a totéž.

Nic nezabrání tomu, aby web zase nabobtnal. Štíhlá statická stránka s tag managerem, cookie lištou, chatovým widgetem a třemi měřicími skripty bude stejně pomalá jako všechno ostatní. Generátor rozhoduje o tom, co nasadíte, ne o tom, co tam později přidá marketing.

Co bych použil já

Většina lidí, kteří se ptají, jaký framework zvolit, by místo toho měla vybírat platformu.

To, co následuje, je moje volba, ne pravidlo. Správná odpověď záleží na týmu a na tom, co firma prodává. Po tolika auditech ale vídám pořád dokola těch pár případů.

Malý nebo středně velký e-shop? Shopify. Postará se o to, o co se starat nechcete – platby, sklad, pokladnu – a jeho šablony si v Core Web Vitals vedou líp než většina vlastních řešení. Do headless přestavby se nepouštějte, pokud nemáte tým, který ji bude pět let provozovat.

Hodně publikujete a redaktoři pracují bez vývojářů? WordPress. Není v módě, a přesto je to správná volba – jen mějte co nejméně pluginů a pořádně nastavte cache.

Všechno ostatní? Hugo nebo Eleventy. Marketingové weby, dokumentace, produktové stránky, programatický obsah – vygenerujte je a JavaScriptu pošlete do prohlížeče jen minimum. To je většina webů a většina toho, co bývá překomplikované.

Opravdu stavíte aplikaci? Pak stavte aplikaci. Next.js je stavěný pro objednávkové procesy, dashboardy a všechno za přihlášením – a umí to dobře. Chybou není, že ho používáte. Chybou je, když na něm postavíte blog.

A pokud přestavba nepřipadá v úvahu – což platí pro většinu enterprise webů – renderujte na serveru nebo staticky generujte aspoň šablony s produkty a cenami. Interaktivní části nechte v prohlížeči. Všichni pak dostanou stejné HTML.

Částečná oprava šablon, které vydělávají, je lepší než kompletní přestavba, kterou nikdo neschválí.

Nejdřív si položte tři otázky

Najdete důležitý obsah v HTML, které přijde ze serveru? Potřebuje něco na stránce stav v prohlížeči, který přežije i další načtení? Může někdo, kdo nepíše kód, publikovat změnu ještě dnes?

Většina týmů neumí na první otázku odpovědět, aniž by se nejdřív podívala. Už to samo napovídá, jak málo z toho kdy bylo vědomé rozhodnutí.

Deset let jsme z webů dělali aplikace. Uživatelé dostali pomalejší stránky. Stroje dostaly stránky, které nepřečtou. A ti, kdo mají obsah na starosti, ho už nemohou měnit.

Překomplikovaný je každý web, který bez prohlížeče neřekne, co na něm je. A platíte za to třikrát.