2026 рік. App Router стабільний понад два роки. Pages Router досі працює, отримує патчі безпеки, і Vercel його не задепрекейтили. Тому питання продовжує спливати: який із них використовувати?
Відповідь залежить від того, починаєш ти проєкт з нуля чи підтримуєш існуючий. Розберемо обидва випадки.
Що App Router реально дає зараз
Коли App Router вийшов, пітч був про Server Components і стримінг. Два роки потому реальні виграші більш практичні:
Лейаути, що переживають навігацію. Шел дашборду, який не ремаунтиться при перемиканні табів. Чекаут-флоу, де сайдбар кошика переживає переходи. В Pages Router це фейкається через _app.tsx і стейт-менеджмент. В App Router — файл layout.tsx.
Server Components за замовчуванням. Компоненти віддають нуль JS на клієнт, поки ти не вкажеш 'use client'. Для контент-важких сторінок — блогів, маркетингових сайтів, документації — це драматично менше JavaScript. Я досягнув Lighthouse 98 на тримовному сайті частково тому, що більшість компонентів ніколи не потрапляють у клієнтський бандл.
Server Actions. Сабміт форм і мутації без API-роутів. Одна функція, один файл, 'use server' зверху. Прибирає цілий шар бойлерплейту. (Хоча є підводні камені, які я дізнався на практиці.)
Parallel routes та intercepting routes. Патерни з модалками, де URL оновлюється, але батьківська сторінка залишається змонтованою. Фотогалереї, модалки логіну, панелі деталей — все з правильною поведінкою кнопки «назад».
Стримінг і Suspense. Шел завантажується миттєво, повільні дані підтягуються потоком. Користувачі бачать щось одразу, а не витріщаються на спінер. Для сторінок з кількома незалежними джерелами даних — помітне покращення UX.
Коли Pages Router досі правильний вибір
Існуючий проєкт працює нормально
Якщо в тебе Pages Router проєкт у продакшні, користувачі задоволені, команда шипить фічі без тертя — не мігруй. Pages Router нікуди не дінеться, а міграція дає нуль нових фіч, які помітять користувачі. Це інженерний час без продуктової віддачі.
Я бачив команди, які витрачали 3–4 тижні на міграцію середніх застосунків на App Router. Результат: той самий застосунок, трохи менше JS, і команда, якій тепер потрібно переучувати патерни, з якими була м'язова пам'ять. Не варто того, якщо не впираєшся в конкретну стелю.
Команда не працювала з App Router раніше
Зсув ментальної моделі реальний. У Server Components є межі серіалізації — не можна передавати функції або обробники подій із серверних компонентів у клієнтські. Керування стейтом змінюється. Отримання даних переїжджає з getServerSideProps в async-компоненти. Обробка помилок працює інакше.
Для команди, нової в App Router, заклади 1–2 тижні на розгін, перш ніж вийдеш на попередню швидкість. На стислих дедлайнах — реальна вартість.
Бібліотеки, що не адаптувалися
Більшість великих бібліотек зараз працюють з App Router. Але якщо проєкт залежить від чогось, що вимагає клієнтського рендерингу повсюди — певні анімаційні бібліотеки, складні drag-and-drop сетапи або нішеві інструменти керування стейтом — спершу перевір сумісність. Обгортати все в 'use client' — значить втрачати сенс.
Шлях міграції: співіснування
Якщо вирішиш мігрувати, Next.js підтримує обидва роутери одночасно. Директорія app/ використовує App Router; директорія pages/ — Pages Router. Вони співіснують в одному проєкті.
Практичний підхід:
- Нові роути йдуть в
app/. Кожна нова сторінка або фіча — на App Router. - Існуючі роути залишаються в
pages/. Не чіпай робочий код. - Мігруй опортуністично. Коли вже переписуєш сторінку для фічевої зміни — перемісти в
app/. - Спільні лейаути — першими. Найбільший виграш від міграції — персистентні лейаути. Почни з них.
Я робив це на двох клієнтських проєктах. Повна міграція зайняла 2–3 місяці опортуністичних змін, з нульовим даунтаймом і без big-bang рерайту. Директорія pages/ зменшувалася природно.
Чесна рекомендація
Починаєш новий проєкт у 2026? Бери App Router. Екосистема підтягнулася, патерни стабільні, і переваги DX (лейаути, Server Components, стримінг) накопичуються за час життя проєкту. Плюс краща документація та підтримка ком'юніті — більшість нових туторіалів, прикладів і гайдів передбачають App Router.
Підтримуєш Pages Router проєкт? Залиш як є. Мігруй тільки якщо впираєшся в конкретні стелі:
- Потрібні персистентні лейаути, і не можна чисто сфейкати їх
- Клієнтський JS-бандл завеликий, і Server Components реально його зменшать
- Додаєш i18n роутинг, і файловий підхід App Router чистіший
Мішаєш обидва? Нормально. Це не тимчасовий хак — так Next.js задуманий для поступового впровадження.
Питання «App Router чи Pages Router?» все ще актуальне у 2026. Але відповідь простіша, ніж два роки тому: бери App Router для нової роботи, не мігруй стару без причини.
Працюєш з Next.js і не впевнений, які патерни підходять твоєму проєкту? Напиши — я допомагаю командам обрати правильну архітектуру, щоб шипити швидше, а не просто по-іншому.