App Router odwraca model SPA: komponenty renderują się na serwerze i wysyłają HTML bez JavaScriptu do klienta. Turbopack zastępuje Webpack — build time spada z 42 sekund do 4.2 sekundy, HMR poniżej 50ms. Każda strona ładuje się z edge CDN zanim loader zdąży zamigać.
Do 2023 typowa strona Next.js była de facto aplikacją SPA okraszoną SSR. Pierwszy request trafiał na serwer, ale browser musiał pobrać, zparsować i zhydrować kompletny bundle JavaScript zanim strona zaczęła reagować. Kolory pojawiały się w ~0.8s, ale interakcja była możliwa po 3–4 sekundach. Ten gap między FCP a TTI to najpoważniejszy problem webowego UX — widać stronę, ale nie można jej używać.
App Router w Next.js 13+ odwrócił ten model. Zamiast wysyłać JS, który potem renderuje HTML w przeglądarce, serwer wysyła gotowy HTML strumieniowo przez HTTP. React Server Components nie generują żadnego JavaScriptu po stronie klienta — dosłownie zero. Klient dostaje tylko JS dla komponentów oznaczonych `'use client'`. W moich projektach to średnio 15–17% drzewa komponentów — reszta renderuje się na serwerze i nie ma żadnego kosztu hydratacji.
Streaming SSR z Suspense boundaries zmienia kolejność renderowania. Zamiast czekać na najwolniejszą część strony, Next.js 16 wysyła HTML w kawałkach — shell layoutu trafia do przeglądarki natychmiast, sekcje z danymi z bazy pojawiają się kolejno. Partial Prerendering idzie krok dalej: statyczny shell generowany w build time, dynamiczne fragmenty streamowane z serwera. Jeden request, zero cold startów, TTFB poniżej 100ms z edge CDN.
Turbopack jako domyślny bundler to nie marketing — to realny skok wydajności narzędzi. Webpack to JavaScript parsujący JavaScript przez JavaScript. Turbopack to Rust z natywnym paraleizmem, inkrementalną kompilacją i cache na poziomie modułu. W projekcie MazCode build pełnego projektu (ponad 150 slice'ów, kilkaset plików TypeScript) trwa kilka sekund na Turbopacku. Ten sam projekt z Webpack: 42 sekundy. HMR po zmianie dowolnego pliku: 18–45ms zamiast 600–800ms.
System routingu file-based w App Router dostarcza coś czego Pages Router nie miał: layouts zagnieżdżone bez re-renderowania, route groups bez wpływu na URL, parallel routes dla komponentów ładujących się niezależnie, intercepting routes dla modali z własnym URL. Dla projektu z 50+ stronami to eliminuje setki linii ręcznej logiki nawigacji.
W MazCode każda strona klienta wychodzi z ISR lub pełnym SSG — statyczny HTML na Vercel Edge Network, zregenerowany automatycznie po zmianie w CMS. LCP dla stron statycznych na edge CDN wychodzi poniżej 1.2s na cold cache, poniżej 0.4s na warm. To bezpośrednie przełożenie na Core Web Vitals score, który Google uwzględnia w rankingach organicznych.
Trade-off, który warto znać: App Router wymaga precyzyjnego myślenia o granicy client/server. Przekazywanie event handlerów przez granicę RSC jest niemożliwe, Context API wymaga wrappera 'use client'. Dla małych projektów z dużą ilością interakcji może to oznaczać więcej plików niż w Pages Router. Dla stron content-first — a takich buduję 90% — to czyste zyski bez istotnych kosztów.
Komponenty renderowane wyłącznie na serwerze — żaden kod komponentu nie trafia do bundle'a klienta. Większość drzewa komponentów renderuje się wyłącznie na serwerze — statyczne sekcje nie wysyłają żadnego JS do przeglądarki, więc bundle klienta jest znacząco mniejszy.
HTML wysyłany strumieniowo przez HTTP z Suspense boundaries jako punktami cięcia. Browser renderuje shell strony natychmiast, sekcje z danymi uzupełniają się kolejno — LCP poniżej 1.2s bez cache.
Rust-based bundler z inkrementalną kompilacją na poziomie modułu. HMR 18–45ms vs 600–800ms w Webpack. Build całego projektu 4.2s zamiast 42s — 10x szybciej w codziennej pracy.
next/image przetwarza obrazy serwer-side: lazy loading z Intersection Observer, responsive srcset, automatyczna konwersja do WebP/AVIF, priorytetowe ładowanie LCP image. Zero ręcznej konfiguracji, zero CLS.
Lekki bundle dzięki RSC architecture — LCP w okolicach 1.2s, minimalny layout shift. Strona ładuje się z edge CDN zanim JavaScript zdąży się zparsować, a w Google Search widać to w rankingach organicznych.