Next.js 15: kdy dává smysl a co ověřit před vývojem
Od tématu ksouvislostem.
Pro majitele digitálních produktů a technické týmy: co přináší App Router, kde jsou hranice Server Actions a proč framework sám nezaručí rychlejší web.
Obsahová úprava průvodce: 15. září 2026. Projektové ukázky a návodné příklady jsou v textu rozlišené.
Začněte požadavky, ne názvem frameworku
Next.js je jedna z možností pro weby a aplikace v Reactu. Při volbě řešení si nejdříve ujasněte obsah, přihlášené uživatele, integrace a způsob správy. App Router je technický prostředek; není sám o sobě obchodní výhodou.
Rozhodnutí z našich projektů: Bike-Centrum potřebovalo změnit prezentaci značky. Připravili jsme návrh ve Figmě a nasadili ho do stávajícího Shoptetu. Termovize Eagle naopak dostaly web v Next.js s vlastní správou produktů a všech textů. Dvě zadání vedla ke dvěma různým řešením; samotný požadavek na nový vzhled neurčil technologii.
Sepište tři hlavní uživatelské scénáře a omezení provozu. Teprve podle nich porovnávejte řešení.
Formulář potřebuje víc než Server Action
Server Actions mohou zjednodušit propojení formuláře a serverové operace. Nejsou ale náhradou za ověření identity, oprávnění nebo vstupních dat. TypeScript neověřuje, co skutečně dorazilo od návštěvníka.
Při návrhu poptávkového formuláře proto řešte také chyby, opakovaný požadavek a potvrzení doručení. Úspěchem není kliknutí na tlačítko, ale bezpečně přijaté a dohledatelné zadání.
Otestujte běžné odeslání, neplatný vstup a opakované kliknutí. Obchodní cesta musí fungovat i při chybě.
Pro vývojáře: PPR v Next.js 15 a měření výkonu
Partial Prerendering v dokumentaci Next.js 15 vyžaduje experimentální konfiguraci a výslovné zapnutí pro příslušné routy. Není správné předpokládat, že se samo aktivuje v každém projektu.
Konkrétní odezva závisí také na databázi, infrastruktuře a obsahu stránky. Bez měření nelze slíbit univerzální TTFB ani procentní zrychlení. Funkce a nastavení vždy ověřujte proti verzi, kterou skutečně provozujete.
Nejdřív změřte pomalou cestu. Experimentální funkci zavádějte až s testem, monitoringem a možností návratu.
Datové závislosti rozhodují o čekání
Při návrhu stránky odlište data, která návštěvník potřebuje hned, od těch doplňkových. Modelový příklad: hlavní informace o produktu nemusí čekat na načtení doporučených položek.
Souběžné načítání má smysl u nezávislých operací. Cache naopak vyžaduje jasné pravidlo, kdy se data obnoví. U ceny, dostupnosti či oprávnění nesmí snaha o rychlost způsobit nepravdivý nebo nepovolený výstup.
Nakreslete cestu od požadavku k datům. U každého údaje určete přípustné stáří a způsob obnovy.
Metadata musí odpovídat skutečné stránce
Metadata API umožňuje sestavit titulek, popis, canonical a sociální náhled ze zdroje obsahu. Samotná konfigurace však neprokazuje, že veřejná stránka vrací správný výsledek.
Zkontrolujte výslednou URL, vykreslené HTML a shodu náhledu s viditelným obsahem. Strukturovaná data vyžadují samostatný obsahově odpovídající výstup; nelze je zaměňovat za automatickou součást titulku.
Po nasazení ověřte konkrétní veřejné stránky, včetně chybějícího obsahu a starých přesměrovaných URL.
Co si připravit před rozhodnutím
Připravte seznam integrací, způsob správy obsahu, očekávané role uživatelů a současné provozní potíže. Návrh řešení má vysvětlit, proč zvolená architektura odpovídá právě těmto potřebám.
Pokud hotová platforma pokrývá zadání, vlastní vývoj nemusí být nejvýhodnější první krok. Přínos se posuzuje podle celkového provozu a údržby, ne podle názvu použité technologie.
Do poptávky pošlete tři scénáře, stávající systém a největší omezení. Na tom lze postavit smysluplnou technickou konzultaci.
Související projekty a dokumentace
V případových studiích najdete rozsah uvedených realizací. Technické detaily ověřujte v dokumentaci pro verzi, kterou používáte.
- Bike-Centrum: redesign na stávajícím Shoptetu
- Termovize Eagle: vlastní správa produktů a textů
- Next.js 15: Partial Prerendering
- Next.js 15: Metadata API