App Router w Next.js to nie jest naturalna ewolucja Pages Routera. To inny framework, który Vercel wciska w tę samą nazwę. W 2026 roku Pages Router nadal ma 64% głosów w oficjalnej ankiecie Vercel (dyskusja #59373, ponad 2000 głosów), a App Router co kilka miesięcy dostaje CVE w warstwie RSC. To nie jest spór o preferencje — to spór o to, czy migracja w ogóle ma sens dla projektów, które nie są aplikacjami z logowaniem i dashboardami.
Argument drugiej strony
Vercel promuje App Router jako domyślny wybór i w nowych projektach create-next-app startuje właśnie od niego. Argumenty są znane: React Server Components, streaming, zagnieżdżone layouty, Server Actions, lepsze dane z serwera. Brzmi rozsądnie. Problem w tym, że część z tych obietnic albo nie dotrzymuje marketingu, albo wiąże się z realnym kosztem, o którym dokumentacja mówi cicho.
W oficjalnej ankiecie Vercel Pages Router wygrywa 64:35. Ankieta nie jest oczywiście próbą losową, ale pytanie brzmi „preferujesz X" i tysiące deweloperów używających Next.js na co dzień odpowiedziało. To sygnał, którego nie da się zignorować.
Dane, nie opinie
Wydajność: App Router jest wolniejszy. Na tym samym hardware i tym samym create-next-app TTFB w App Routerze potrafi być dwukrotnie dłuższy niż w Pages Router. W benchmarku z wrk na stacku bull-board + hone (dyskusja #67048) Pages Router osiągnął 7712 req/s przy średnim opóźnieniu 12.77 ms, a App Router 3085 req/s przy 24.15 ms — czyli App Router był ponad 2.5x wolniejszy pod obciążeniem. To nie jest anegdota, to pomiar w Next.js 15.
Bezpieczeństwo: RSC ciągle się sypie. 11 grudnia 2025 Vercel opublikował security update z dwoma podatnościami w React Server Components: CVE-2025-55184 (Denial of Service, wysoka ważność, nieskończona pętla przy deserializacji) i CVE-2025-55183 (Source Code Exposure, średnia ważność, wyciek kodu Server Functions). Aplikacje Pages Routera nie były dotknięte żadną z nich. Aktualizacja jest obowiązkowa, workarounds nie ma — musisz podbić wersję Next.
DX: pełzający bałagan. W poście o migracji (Flightcontrol) ich inżynier napisał: „Dev server jest tak wolny, że oddałbym wszystkie dobre rzeczy z App Routera, żeby go nie używać. Przesiadłbym się na inny framework. Przesiadłbym się na inny język." Trzeba restartować serwer co 20 minut, bo wycieka pamięć. Komentarze na GitHubie pod dyskusją #59373 pełne są podobnych głosów: niejasna granica server vs client, hot reload popsuty na Windows, błędy bez stack trace'a, dokumentacja wciąż miesza przykłady z Pages.
Kiedy App Router ma sens
App Router jest dobrym wyborem, jeśli Twój projekt to aplikacja: panel klienta, dashboard z logowaniem, narzędzie z dużą ilością stanu po stronie klienta. W takich projektach zagnieżdżone layouty, Server Actions i możliwość wyboru co renderować statycznie, a co dynamicznie, dają realną przewagę. Flightcontrol dobrze to opisuje — side panel w dashboardzie, persystencja layoutu przy nawigacji między siblingami, to jest coś, czego Pages Router nie umie.
Jeśli robisz stronę firmową, blog, landing page, dokumentację, prosty e-commerce bez logowania — Pages Router wystarczy. Przy małej ilości komponentów klienckich App Router nie daje Ci nic, a zabiera czas na naukę mentalnego modelu RSC. W testach wydajności content site'ów Next.js wysyła około 463 KB JS (bench 2026), co jest tragicznym wynikiem dla strony, która ma tylko wyświetlać tekst i obrazki. Jeśli liczy się dla Ciebie Core Web Vitals na content site, Astro albo czysty SSG w Next wygrywa z App Routerem bez dyskusji.
Doświadczenie z prawdziwego projektu
Robiliśmy ostatnio migrację średniej wielkości SaaSu (klient z sektora logistyki) z Pages Routera na App Router. Powód był uzasadniony: potrzebowaliśmy zagnieżdżonego layoutu dla panelu ustawień z bocznym menu, które nie znika przy zmianie podstrony. Migracja trwała trzy tygodnie, z czego większość czasu zeszła nie na layout, tylko na poprawki auth flow — token w HTTP-only cookie, odczyt w Server Component, przekazanie do klienta. To, co w Pages było dwoma linijkami w _app.tsx, w App Routerze rozjechało się na cztery pliki. Efekt końcowy: layout działa, performance spadł o ok. 18% na TTFB na produkcji (self-hosted Node, nie Vercel). Klient zaakceptował, bo layout był dla niego ważniejszy niż TTFB. Ale gdyby to była strona marketingowa, nie wdrożylibyśmy App Routera.
Co bym wybrał dziś
Dla nowego projektu w 2026: Next.js z Pages Routerem dla stron contentowych i małych aplikacji, App Router tylko wtedy, gdy naprawdę potrzebujesz zagnieżdżonych layoutów i RSC. Jeśli Twój use case to „zwykła strona z formularzem kontaktowym i blogiem" — zostań przy Pages albo idź w Astro. Jeśli masz istniejący projekt na Pages Routerze i on działa — nie migruj, chyba że masz konkretny feature, którego nie da się zrobić inaczej. Koszt migracji jest realny, a korzyść dla większości biznesów jest żadna.
Trzymaj też rękę na pulsie bezpieczeństwa: jeśli mimo wszystko wybierasz App Router, zasubskrybuj GitHub Security Advisories dla next.js i aktualizuj od razu po ogłoszeniu CVE. RSC to młody kod i regularnie dostaje łatki, których nie da się obejść.
Jeśli porównujesz App Router z innymi podejściami do renderowania, sprawdź nasz wcześniejszy tekst o stronach dedykowanych vs WordPress — inny temat, ale podobne pytanie u źródła: kiedy warto płacić za custom, a kiedy wystarczy proste rozwiązanie.