Vydání Next.js 15 a 16 znamená zásadní posun v tom, jak přistupujeme k webovému výkonu. Opustili jsme éru „magického“ implicitního cachování a vstoupili do éry explicitní, granulární kontroly. S představením stabilního React Compilera, Partial Prerendering (PPR) a revoluční direktivy use cache dospěl App Router do podoby vysoce výkonného enginu schopného doručovat obsah v řádu milisekund i u komplexních aplikací náročných na data.
Optimalizace aplikace v Next.js v roce 2025 už není jen o minifikaci JavaScriptu; je to o orchestraci pohybu dat mezi serverem a klientem s chirurgickou přesností. Tento průvodce prozkoumá pokročilé techniky vyžadované k ovládnutí výkonu v moderním ekosystému Next.js.
Revoluce v cachování: Od implicitního k explicitnímu
V dřívějších verzích App Routeru bylo cachování často „implicitní“. Jediné volání dynamické funkce jako cookies() nebo headers() mohlo nečekaně vyřadit celou routu z cachování. Next.js 16 to zásadně mění modelem „Cache Components“.
Direktiva use cache
Direktiva use cache je nejvýznamnějším pokrokem v Next.js 16. Umožňuje vývojářům explicitně se přihlásit k cachování na úrovni funkce nebo souboru. Tím končí nepředvídatelnost předchozího modelu cachování.
- Cachování na úrovni funkcí: Nyní můžete zabalit konkrétní logiku (jako dotaz do databáze nebo volání externího API) do asynchronní funkce a označit ji
'use cache';. Next.js nacachuje návratovou hodnotu na základě serializovaných argumentů. - Cachování na úrovni souboru: Umístěním
'use cache';na začátek souboru nacachujete každou exportovanou funkci v daném souboru.
// services/products.ts
import { unstable_cacheLife as cacheLife } from 'next/cache';
export async function getProductDetails(productId: string) {
'use cache'; // Explicitní přihlášení k cachování této funkce
cacheLife('minutes'); // Definice profilu vypršení platnosti
const res = await fetch(`https://api.acme.com/products/${productId}`);
if (!res.ok) throw new Error('Failed to fetch product');
return res.json();
}API pro granulární kontrolu cache
Pro podporu tohoto explicitního modelu zavedl Next.js několik nových API pro správu cache:
cacheLife: Nahrazuje starší konstantyrevalidate. Přijímá profily jako'minutes','hours'nebo'days', což usnadňuje správu TTL (Time To Live) napříč různými prostředími.cacheTagarevalidateTag: Tyto zůstávají zlatým standardem pro invalidaci na vyžádání. Označením nacachovaného segmentu tagem jej můžete okamžitě vymazat, když se data změní (např. po webhooku z CMS).
Ovládnutí renderovacích vzorů: PPR a Streaming
Cílem optimalizace výkonu je snížit Time to First Byte (TTFB) a Interaction to Next Paint (INP). Next.js 16 toho dosahuje díky stabilizaci Partial Prerendering (PPR).
Stabilní Partial Prerendering (PPR)
PPR umožňuje kombinovat statické a dynamické renderování na stejné stránce bez složité konfigurace. Když uživatel požádá o stránku, Next.js okamžitě odešle statický HTML shell (obsahující layout, navigaci a statický obsah). „Dynamické díry“ — části stránky, které vyžadují data specifická pro uživatele — jsou zabaleny do hranic <Suspense> a streamovány, jakmile jsou připraveny.
Chcete-li povolit PPR, nakonfigurujte jej v next.config.js:
// next.config.js
const nextConfig = {
experimental: {
ppr: 'incremental', // Postupná adopce PPR napříč routami
},
};
module.exports = nextConfig;Role Reactu 19 a React Compilera
Next.js 16 využívá stabilní React Compiler. Dříve vývojáři trávili značné množství času ruční optimalizací komponent pomocí useMemo, useCallback a React.memo, aby zabránili zbytečným re-renderům. React Compiler tento proces automatizuje analýzou kódu a aplikací memoizace tam, kde přináší největší užitek.
To vede k:
- Méně práce pro hlavní vlákno (Main Thread): Komponenty se re-renderují pouze tehdy, když se změní jejich skutečné datové závislosti.
- Zlepšení INP: Snížením práce, kterou React vykonává během aktualizací, zůstává prohlížeč responzivní na uživatelské vstupy.
Strategie pro vysoce výkonné načítání dat
Načítání dat je často hlavním úzkým hrdlem webových aplikací. V App Routeru se musíme posunout od sekvenčních „vodopádů“ (waterfalls) k paralelnímu provádění a streamování.
Eliminace request waterfallů
Běžnou chybou je postupné čekání (await) na více volání fetch za sebou. To nutí druhý požadavek čekat na dokončení prvního, čímž se zdvojnásobuje latence.
Anti-pattern (Pomalé):
const user = await getUser(); // Trvá 500ms
const posts = await getPosts(user.id); // Trvá 500ms (Celkem: 1000ms)Optimalizovaný vzor (Rychlé):
// Spuštění obou požadavků paralelně
const userPromise = getUser();
const postsPromise = getPosts();
// Čekání na vyřízení obou
const [user, posts] = await Promise.all([userPromise, postsPromise]);Využití Server Components pro optimalizaci „listů“
Chcete-li minimalizovat JavaScript bundle odesílaný klientovi, měli byste udržovat své „Client Components“ na koncích (listech) stromu komponent. Pokud označíte layout na vysoké úrovni jako "use client", každá komponenta importovaná do tohoto layoutu se stane součástí klientského bundlu.
Místo toho předávejte Server Components jako children nebo props do Client Components, abyste zachovali výhodu „Server-First“.
// Špatně: Celá stránka je Client Component
"use client"
export default function Dashboard({ data }) {
return <Sidebar>{/* komplexní logika */}</Sidebar>;
}
// Správně: Pouze interaktivní přepínač je Client Component
export default function DashboardPage() {
return (
<Sidebar>
<Suspense fallback={<Skeleton />}>
<DataList /> {/* Server Component */}
</Suspense>
<InteractiveToggle /> {/* Client Component */}
</Sidebar>
);
}
Optimalizace assetů a přechod na Turbopack
Assety — obrázky, fonty a skripty — často tvoří největší část váhy stránky. Next.js poskytuje vestavěné nástroje pro jejich automatické zpracování.
Optimalizace obrázků pomocí next/image
Komponenta next/image je víc než jen tag <img>. V roce 2025 je nezbytné používat atribut priority pro elementy Largest Contentful Paint (LCP) a atribut sizes, aby se zabránilo stahování obrázků, které jsou pro viewport příliš velké.
<Image
src="/hero.jpg"
alt="Hero Image"
width={1200}
height={600}
priority // Zásadní pro LCP
sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw"
/>Optimalizace fontů a nulový layout shift
Použití next/font vám umožňuje hostovat fonty lokálně a automaticky spravuje vlastnost font-display. To eliminuje Layout Shift (CLS) způsobený načítáním fontů po počátečním vykreslení. Použitím CSS proměnných s next/font zajistíte, že vaše typografie bude připravena v momentě, kdy je HTML parsováno.
Turbopack: Nový standard
S Turbopackem, který je nyní v Next.js 16 výchozím bundlerem, se časy buildu a rychlost Fast Refresh dramaticky zlepšily. Turbopack využívá engine pro inkrementální výpočty napsaný v Rustu, který rekompiluje pouze přesně ten kód, který se změnil. U rozsáhlých aplikací to může zkrátit čas produkčního buildu až o 80 %.
Monitorování a validace v reálném světě
Optimalizace výkonu není úkol typu „nastav a zapomeň“. Svá vylepšení musíte validovat pomocí Real User Monitoring (RUM).
- Vercel Speed Insights: Tento nástroj poskytuje živý dashboard metrik Core Web Vitals (LCP, INP, CLS) vaší aplikace na základě skutečných uživatelských dat.
- Sentry a OpenTelemetry: Pro hlubší vhledy, zejména v Server Components a API routách, použijte trasování založené na OpenTelemetry. To vám umožní přesně vidět, který databázový dotaz nebo volání externího API zpomaluje váš Server Side Rendering (SSR).
- Zod pro bezpečnost za běhu: I když to není přímý nástroj pro „rychlost“, použití Zod pro validaci odpovědí API zajišťuje, že vaše aplikace nespadne nebo nezamrzne kvůli neočekávaným tvarům dat, což může vést ke špatnému vnímanému výkonu.
Často kladené otázky
Jak optimalizovat výkon v Next.js App Routeru?
Optimalizace v App Routeru se soustředí na používání Server Components ve výchozím nastavení pro snížení JavaScriptu na straně klienta a implementaci Partial Prerendering (PPR) pro rychlé počáteční načtení. Dále využijte direktivu use cache pro granulární cachování dat a zajistěte používání next/image a next/font pro optimalizaci assetů.
Je Next.js App Router rychlejší než Pages Router?
App Router je obecně rychlejší, protože umožňuje používat React Server Components (RSC), které výrazně snižují množství JavaScriptu odesílaného do prohlížeče. Podporuje také pokročilé funkce jako Streaming a Partial Prerendering, které v Pages Routeru nejsou k dispozici, což vede k lepším výsledkům Core Web Vitals.
Jak snížit velikost JavaScript bundlu v Next.js?
Chcete-li snížit velikost bundlu, přesuňte interaktivitu do „listů“ (leaves) stromu komponent a používejte dynamické importy (next/dynamic) pro těžké knihovny třetích stran. Vyhněte se umisťování direktivy "use client" na nejvyšší úroveň vašich layoutů, protože to nutí všechny dceřiné komponenty do klientského bundlu.
Jak funguje cachování v Next.js App Routeru?
V Next.js 16 je cachování explicitní prostřednictvím direktivy use cache, která umožňuje cachovat funkce nebo soubory se specifickými TTL profily pomocí cacheLife. Využívá také víceúrovňový systém cachování, včetně Request Memoization, Data Cache a Full Route Cache, aby se minimalizovalo redundantní zpracování.
Jaké jsou nejlepší postupy pro načítání dat v Next.js?
Vždy načítejte data na serveru pomocí Server Components, abyste udrželi logiku blízko zdroji dat a snížili režii na straně klienta. Používejte paralelní načítání s Promise.all, abyste se vyhnuli waterfallům, a zabalte pomalá načítání dat do hranic <Suspense>, čímž povolíte streamování pro lepší uživatelský zážitek.
Závěr
Optimalizace výkonu v Next.js App Routeru je cestou k explicitní kontrole. Přijetím direktivy use cache, využitím Partial Prerenderingu a ponecháním nízkoúrovňových optimalizací na React Compileru můžete stavět aplikace, které jsou nejen rychlé, ale také odolné a udržovatelné.
Když se díváme směrem k budoucnosti webu v letech 2025 a 2026, zaměření se přesunulo od „kolik toho můžeme poslat klientovi“ k „jak málo toho skutečně potřebujeme“. Dodržováním těchto osvědčených postupů zajistíte, že vaše aplikace v Next.js zůstanou na špičce v rychlosti a uživatelském zážitku.