Astro vs Next.js 15: когда что выбрать в 2026

18 апреля 2026 г. 18K

Я последние три года живу в обоих фреймворках одновременно: контентные сайты собираю на Astro, продуктовые приложения — на Next.js. К 2026 году стало проще объяснять разницу: фреймворки разъехались по нишам сильнее, чем были на старте, и выбор перестал упираться в «что моднее».

В этой статье я не буду писать «X побеждает Y». Сравню по реальным сценариям и расскажу, когда в проекте у меня лежит Astro, а когда я с первого дня тяну Next.

Архитектура: откуда растут различия

Astro изначально про контент. Его основной шаблон — статические страницы с редкими интерактивными островами. Если нужна динамика, ты включаешь SSR через адаптер и пишешь prerender = false точечно. Маршрутизация — файловая, без слоёв.

Next.js — фронтенд-фреймворк для приложений. App Router строится вокруг React Server Components, серверных экшенов, layout-ов и Suspense. Его «суперсила» в том, что серверный и клиентский код живут в одном дереве, а данные подтягиваются ближе к месту использования. Минус — этой мощи нужно учиться, и она тащится в любой простой проект.

Когда я беру Astro

Если задача попадает в один из этих сценариев — почти всегда Astro:

контент-сайт, корпоративный лендинг, документация;
блог с поиском по предсобранному индексу;
портал, где 90% страниц — публичные и редко меняются;
сайт с лёгкими интерактивами, которые не должны загружать весь React.

Один из недавних кейсов: запустил онлайн-журнал на 200+ статей. Astro собирал статику за 14 секунд, итоговый клиентский бандл — 18 КБ gzip на главной (только islands со счётчиком и поиском). Next.js на ту же задачу выдавал 110+ КБ только из-за рантайма React, без какой-либо реальной интерактивности.

Когда я беру Next

SaaS с авторизацией, ролями, ролевыми зонами;
дашборды, где много форм, мутаций и табличной логики;
проект, который завтра обзаведётся командой из десяти человек;
интернет-магазин, где CMS, корзина и поиск живут в одной системе.

Next в 15 ощутимо вырос: server actions стабилизировались, partial prerendering из эксперимента превратился в опцию, которой реально можно пользоваться, кеш-API стал предсказуемым. Если у тебя сложная серверная логика и React-эко всё равно нужен — нет смысла спорить, Next подходит лучше.

Размер бандла

Astro выигрывает за счёт того, что по умолчанию не отправляет в браузер ничего. На каждую интерактивную область ты включаешь рантайм осознанно. Это сделано настолько хорошо, что в продакшене у меня лендинг весит 0 КБ JS.

Next грузит React. Даже на странице, которая не имеет интерактивной части. RSC помогает: серверные компоненты рендерятся на сервере и не утаскивают код в клиент. Но рантайм React всё равно нужен для гидрации хотя бы одного клиентского узла, и без него полностью статичной страницы не получить.

SSR-производительность

Astro в SSR заметно быстрее на простых страницах: меньше прослоек, маленький рантайм. Next переигрывает там, где запрос упирается в работу с данными — потому что Streaming-SSR позволяет начать отдавать HTML ещё до того, как все данные собраны.

Я когда-то ставил эксперимент: одна и та же страница со списком из 30 элементов и подвалом. Astro отдавал 200 OK за ~12 мс, Next — за ~40 мс. На странице с 6 параллельными вызовами к API, наоборот, Next отдавал первый байт за 18 мс благодаря streaming, а Astro молчал ~120 мс до полной готовности HTML. У каждого профиль свой.

Серверные экшены и формы

В Next 15 server actions — основной способ обработки форм. Записал функцию с 'use server', повесил её на форму через action={...}, получил типизированный поток данных. Удобно, но требует понимания, какие данные на каком уровне отрабатывают.

В Astro серверные экшены тоже есть — добавили в 4.15 и расширили в 5. Импортируешь defineAction, кладёшь в src/actions/index.ts, и из любой .astro-страницы или клиентского острова дёргаешь action как функцию. Эргономика не такая глубокая, как у Next, но базу закрывает.

Маршрутизация

Файловая в обоих, но Next накручивает поверх неё несколько концепций: layout.tsx, loading.tsx, error.tsx, route groups в скобках, параллельные слоты с @modal. Это даёт огромную выразительность, но новичка ломает.

В Astro — две сущности: src/pages/*.astro для маршрутов и src/layouts/*.astro для общих обёрток. Всё. Если делаешь сайт с нелинейной структурой — Astro проще. Если делаешь приложение с тремя видами модалок и параллельным рендером — Next.

Команда и обучение

Astro проще для нового человека. Если разработчик знает HTML, CSS и базу JS, он напишет полезную страницу в первый день. Серверные части тоже понятны — там, по сути, JS поверх Vite.

Next требует понимания React, серверных компонентов, режимов кеширования, поведения 'use client' и 'use server'. Без этого ловишь странные ошибки гидрации и непонимания, почему данные обновляются с задержкой. Команде с опытом — нормально, новичку — больно.

Когда я беру оба сразу

Бывает. На крупном проекте у меня документация и блог живут на Astro, а само приложение — на Next.js. Связаны через одинаковый дизайн-токен и общий API. Astro отдаёт быстрый контент и стабильный SEO, Next — продукт с интерактивом. Делиться можно через монорепо.

Подведу черту по сценариям

Лендинг или сайт с малой интерактивностью — Astro.
Блог или документация — Astro.
Магазин с корзиной, оформлением, личным кабинетом — Next.
Дашборд или админка — Next.
SaaS с авторизацией и подписками — Next.
Гибридный проект (контент + продукт) — оба, разделённые по бизнес-зонам.

Что копать дальше

Если думаешь над выбором — поставь оба, реализуй главную страницу проекта в каждом, померяй TTFB, FCP, посмотри размер JS. Через час у тебя будет два рабочих скелета и понимание, какой ощущается естественнее. Для большинства команд именно ощущение от каждодневной работы решает больше, чем абсолютные метрики.