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 и не уверен, какие паттерны подходят твоему проекту? Напиши — я помогаю командам выбрать правильную архитектуру, чтобы шипить быстрее, а не просто по-другому.