Для маркетингового сайта, который в основном отдаёт контент - блог, лендинги, страницы услуг, - Astro обычно даёт более высокий Core Web Vitals из коробки за счёт архитектуры islands и нулевого JavaScript по умолчанию. Next.js оправдан, когда сайт должен делить компоненты и код с продуктовым приложением на React или требует тяжёлой клиентской интерактивности - калькуляторов, интерактивных демо, персонализированных виджетов.
В проектах по разработке и переезду сайтов Exceltic.dev регулярно видит один и тот же паттерн: команда выбирает фреймворк по популярности или по тому, на чём уже пишет продукт, а не по тому, что реально отдаётся браузеру. Итог - маркетинговый сайт на Next.js с client-side рендерингом всей главной страницы ради статичного лендинга с формой подписки, где 300-400 КБ JavaScript грузится без всякой необходимости.
Это не абстрактная инженерная деталь. Core Web Vitals напрямую влияют на позиции в Google и на конверсию: по данным web.dev, страницы с плохими показателями LCP и INP теряют пользователей ещё до того, как контент дочитан до конца. Выбор фреймворка на старте определяет, сколько усилий потребуется, чтобы держать сайт быстрым через год роста контента и виджетов.
Дальше - таблица прямого сравнения, честный разбор сценариев для каждого фреймворка и разница в производительности не как маркетинговый слоган, а как архитектурное следствие.
Astro vs Next.js: сравнение для маркетингового сайта
| Параметр | Astro | Next.js |
|---|---|---|
| JS по умолчанию | Ноль, только для интерактивных островов | React-рантайм грузится на каждой странице (если не настроено иначе) |
| Лучше всего для | Блог, лендинги, документация, контентные сайты | Продукт с общим кодом, дашборды, тяжёлая интерактивность |
| Кривая обучения | Низкая - HTML/CSS/JS, любой UI-фреймворк по выбору | Средняя - требует понимания React, серверных компонентов, роутинга |
| Экосистема | Растущая, интеграции для React/Vue/Svelte/Preact | Крупнейшая в React-мире, Vercel, огромное количество библиотек |
| CWV из коробки | Обычно выше без ручной оптимизации | Требует осознанной настройки (Server Components, code splitting) |
Astro - когда выбирать
Astro подходит, если сайт - это в первую очередь контент: статьи, страницы услуг, лендинги, документация. Фреймворк собирает страницы в статический HTML на этапе сборки и по умолчанию не отправляет в браузер ни строчки JavaScript.
Islands architecture: архитектура, при которой интерактивные компоненты (форма, карусель, чат-виджет) рендерятся как изолированные “острова” внутри статической HTML-страницы, а весь остальной контент остаётся чистой разметкой без JS.
Если на странице нужен один интерактивный виджет - например, форма с валидацией на клиенте, - Astro загрузит JavaScript только для этого конкретного компонента, а не для всей страницы. Директива client:visible подгружает код острова только когда пользователь долистал до него, client:idle - когда браузер освободился после первичной отрисовки.
Пример: интерактивный остров в Astro
---
import ContactForm from '../components/ContactForm.jsx';
---
<html>
<body>
<h1>Заголовок статичной страницы</h1>
<p>Этот текст - чистый HTML, без единого байта JS.</p>
<ContactForm client:visible />
</body>
</html>Важное преимущество для команд, которые не пишут на React: Astro не привязывает вас к одному UI-фреймворку. Компонент можно написать на React, Vue, Svelte или на самом Astro - и смешивать их на одной странице через официальные интеграции.
Выбирайте Astro, если:
- сайт в основном контентный - блог, лендинги, страницы услуг, документация
- команда строит сайт с нуля и хочет управляемую модель контента через Headless CMS
- важны Core Web Vitals без ручной оптимизации на старте
- нет задачи делить код с продуктовым web-приложением
Next.js - когда выбирать
Next.js оправдан, когда маркетинговый сайт - не изолированный проект, а часть более широкой продуктовой экосистемы на React. Если команда разработки уже пишет приложение на Next.js и хочет переиспользовать дизайн-систему, компоненты и бизнес-логику между продуктом и сайтом - это весомый архитектурный аргумент в пользу единого стека.
Next.js даёт полный спектр стратегий рендеринга: SSG (Static Site Generation) для статичных страниц, ISR (Incremental Static Regeneration) для страниц, которые обновляются по расписанию без полного ребилда, и SSR (Server-Side Rendering) для персонализированного контента, который нельзя закэшировать заранее.
Это критично, если на маркетинговом сайте есть интерактивные функции, требующие постоянной клиентской логики: калькулятор стоимости, интерактивный демо-виджет продукта, персонализированный контент на основе поведения пользователя. React Server Components в App Router позволяют держать часть логики на сервере и отправлять на клиент только то, что действительно нужно для интерактивности - но эту оптимизацию нужно настраивать осознанно, по умолчанию Next.js так не работает.
Выбирайте Next.js, если:
- сайт делит код, дизайн-систему или бизнес-логику с продуктовым приложением
- нужна тяжёлая клиентская интерактивность - калькуляторы, интерактивные демо, персонализация
- команда разработки уже работает в экосистеме React и не готова вводить второй стек
- нужен ISR для страниц, которые обновляются часто, но не в реальном времени
Производительность - почему это не только про фреймворк
Оба фреймворка могут показывать отличные Core Web Vitals - и оба могут показывать плохие. Разница не в теоретическом пределе скорости, а в том, насколько легко случайно получить медленный сайт.
Next.js по умолчанию отправляет в браузер React-рантайм, даже если странице не нужна ни одна интерактивная функция. Чтобы приблизиться к нулевому JS, команде нужно осознанно настраивать Server Components, разделять клиентские и серверные границы, следить за размером бандла. Это решаемая задача, но она требует дисциплины и понимания архитектуры на уровне каждого компонента.
Astro устроен так, что медленный сайт получить сложнее, чем быстрый. Zero-JS по умолчанию означает, что разработчику нужно осознанно добавить client:*-директиву, чтобы отправить JavaScript в браузер. Ошибка по умолчанию - в сторону производительности, а не против неё.
По состоянию на Q2 2026 официальная документация Astro и Next.js подтверждают эту разницу в философии: Astro описывает себя как content-first фреймворк с opt-in интерактивностью, Next.js - как full-stack React-фреймворк с гибкой, но по умолчанию более тяжёлой моделью рендеринга.
Для маркетингового сайта, где 90% страниц - это статичный контент, а не приложение, разница в “цене ошибки по умолчанию” и определяет, какой фреймворк реалистичнее удержит хорошие CWV через год роста команды контента и новых лендингов.
Как выбрать под вашу ситуацию
Прежде чем выбирать фреймворк, ответьте на четыре вопроса.
Делит ли сайт код с продуктовым приложением? Если да и продукт на React - Next.js снижает трение между командами. Если сайт полностью независим - это не аргумент в пользу Next.js.
Сколько на сайте реальной клиентской интерактивности? Форма подписки и меню - не интерактивность в этом смысле, Astro закроет это островами. Калькулятор с живым пересчётом, персонализированный дашборд для лида - это довод в пользу Next.js.
Кто будет писать контент? Если это нетехнические маркетологи через Headless CMS - оба фреймворка одинаково хорошо работают с Sanity, Contentful или Strapi через официальные интеграции. Разница здесь не критична.
Какой у команды опыт с React? Если разработчики уже пишут на React и не хотят второй стек - Next.js снижает порог входа. Если команда небольшая или привлекает подрядчиков - более простая ментальная модель Astro (HTML-первый подход) снижает риск при передаче проекта.
Реальный кейс: переезд лендинга с Next.js на Astro
SaaS-компания держала маркетинговый сайт (12 страниц: главная, лендинги по сегментам, блог) на Next.js, унаследованном от продуктовой команды. Сайт не имел никакой сложной интерактивности - формы, карточки кейсов, блог с 40 статьями.
PageSpeed Insights показывал 61 на мобильных: React-рантайм и гидратация всего дерева компонентов грузились на каждой странице, включая статичный блог. Аудит показал, что 280 КБ JavaScript отправлялись без единой интерактивной функции, которая бы их использовала.
Переезд на Astro занял три недели для одного разработчика: перенос компонентов на Astro-синтаксис, настройка островов для формы захвата лида и виджета чата, подключение Headless CMS для блога. React-компоненты формы и чата остались без переписывания - Astro подключил их через @astrojs/react интеграцию как острова.
Результат: PageSpeed вырос с 61 до 96 на мобильных. LCP снизился с 3.8 секунды до 1.4 секунды. Объём JavaScript на главной странице упал с 280 КБ до 18 КБ - именно столько нужно для формы и виджета чата, ничего лишнего.
Для кого это актуально
Решение особенно важно для стартапов и SaaS-компаний, которые строят или пересобирают маркетинговый сайт отдельно от продукта: команды 15+ человек, где маркетинг и разработка продукта - разные потоки работы, а сайт нужно обновлять часто и быстро, не трогая продуктовый деплой.
Если продукт и сайт технически и организационно разделены - выбор фреймворка для сайта не обязан копировать стек продукта. Если разделения нет и одна команда поддерживает и то, и другое - единый стек на Next.js снижает когнитивную нагрузку ценой более тяжёлого JS по умолчанию.
Часто задаваемые вопросы
Можно ли использовать React-компоненты в Astro?
Да. Astro поддерживает официальные интеграции для React, Vue, Svelte и Preact - можно взять существующие React-компоненты (например, готовую библиотеку UI-виджетов) и подключить их как острова через @astrojs/react. Компонент рендерится статически на сервере и гидратируется на клиенте только при срабатывании выбранной директивы (client:load, client:visible, client:idle). Это удобно, когда команда хочет сохранить существующую библиотеку компонентов, но не хочет отправлять React-рантайм на каждую страницу.
Что быстрее - Next.js или Astro?
При условии одинаково тщательной оптимизации оба фреймворка способны показывать отличные Core Web Vitals. Разница не в теоретическом максимуме, а в поведении по умолчанию: Astro отправляет ноль JS, пока разработчик явно не укажет обратное, а Next.js по умолчанию загружает React-рантайм на каждую страницу. Для контентного маркетингового сайта это означает, что Astro статистически проще держать быстрым без постоянного внимания к бандлам.
Подходит ли Astro для сайта с личным кабинетом или сложным приложением?
Не как основной инструмент. Astro проектировался под content-first сценарии - блоги, лендинги, документацию. Для полноценного приложения с состоянием, авторизацией на каждой странице и постоянной клиентской логикой (личный кабинет, дашборд) Next.js или чистый React-стек подходят лучше. Гибридный вариант тоже существует: маркетинговый сайт на Astro, а приложение - отдельно на Next.js, с общим дизайн-токенами через shared-пакет.
Сложно ли мигрировать с Next.js на Astro?
Сложность зависит от объёма клиентской логики. Статичные страницы (блог, лендинги без сложных форм) переносятся быстро - разметка и стили почти не меняются, JSX превращается в Astro-компоненты с минимальными правками. Компоненты с состоянием и интерактивностью можно оставить на React и подключить как острова без переписывания. В типовом проекте из 10-15 страниц миграция занимает 2-4 недели для одного разработчика, включая настройку Headless CMS и QA.
Какой фреймворк проще для нетехнической команды редакторов?
Для самих редакторов разницы почти нет - оба фреймворка обычно работают через Headless CMS (Sanity, Contentful, Strapi), и редактор видит только интерфейс CMS, а не код фреймворка. Разница проявляется на стороне разработки: Astro-компоненты ближе к обычному HTML и проще для разработчиков без глубокого опыта в React, что может ускорить онбординг нового подрядчика или штатного разработчика.
Если вы выбираете стек для нового маркетингового сайта или оцениваете переезд с текущего фреймворка - опишите задачу команде Exceltic.dev. Разберём архитектуру под вашу ситуацию: продуктовый стек, объём интерактивности, размер команды - и предложим решение без привязки к тому, что просто “популярно”.