Выбор фреймворка имеет смысл начинать не с популярности и не с синтетического теста, а с устройства будущего продукта. Блог, документация и каталог статей предъявляют другие требования, чем личный кабинет, визуальный редактор или SaaS с большим количеством пользовательского состояния.
Для Smooth Flow я выбрал Astro. Ниже не попытка объявить один инструмент победителем, а разбор условий, при которых каждый из них оказывается рациональным выбором.
Короткий ответ
Astro обычно удобнее, если основа проекта — документы и страницы, большая часть интерфейса не требует постоянной работы JavaScript в браузере, а контент должен собираться в статический HTML.
Next.js обычно удобнее, если приложение уже живёт в экосистеме React, использует сложную авторизацию, серверные действия, персонализированные данные или большое количество интерактивных компонентов.
Главный вопрос звучит так:
Что является центром продукта: документ, который иногда становится интерактивным, или приложение, которое иногда показывает документы?
Для первого случая естественнее Astro, для второго — Next.js.
Как различается базовая модель
Astro начинает со статического HTML
Компоненты Astro по умолчанию выполняются во время сборки или на сервере и не отправляют свой JavaScript в браузер. Интерактивный компонент подключается отдельно как остров с явной директивой, например client:visible или client:idle.
Это полезное ограничение. Разработчику приходится обозначить, какой элемент действительно нуждается в гидрации, вместо того чтобы автоматически превращать всю страницу в клиентское приложение.
На этом сайте JavaScript нужен для мобильного меню, индикатора чтения и нескольких небольших улучшений интерфейса. Основной текст, ссылки и навигация остаются полноценным HTML даже без выполнения клиентского кода.
Next.js начинает с React
Современный App Router разделяет Server Components и Client Components. Серверные компоненты позволяют выполнять значительную часть работы без отправки соответствующего JavaScript в браузер. Это уже не модель «весь React обязательно гидрируется».
Но интерфейс всё равно строится внутри React-архитектуры. Как только компонент требует состояния, обработчика события или браузерного API, появляется граница "use client", а вместе с ней — клиентский пакет и гидрация.
Для приложения это сильная модель. Для простого контентного сайта она может оказаться дополнительным слоем, который нужно контролировать.
Производительность: не фреймворк, а результат
Нельзя честно сказать, что любой сайт на Astro автоматически быстрый, а любой сайт на Next.js медленный. Производительность ломают изображения без размеров, сторонние виджеты, тяжёлые шрифты, аналитика, большие клиентские компоненты и неудачная работа с кешем.
Разница в стартовой позиции:
| Критерий | Astro | Next.js |
|---|---|---|
| JavaScript по умолчанию | Не отправляется для .astro-компонентов | Зависит от границ Server/Client Components |
| Статическая генерация | Основной сценарий | Поддерживается |
| Частичная гидрация | Явные острова | Клиентские поддеревья React |
| Изображения | Встроенный image pipeline | Встроенный next/image |
| Динамический сервер | Подключается адаптером | Центральная часть платформы |
Для оценки нужен не общий балл Lighthouse, а реальные показатели LCP, INP и CLS на целевых устройствах. Важно также смотреть объём переданного JavaScript, количество долгих задач и поведение страницы после загрузки.
Работа с контентом
Коллекции Astro
Content Collections дают схему frontmatter, типизацию и единый API для Markdown или MDX. Ошибка в категории, дате или обязательном поле обнаруживается во время разработки, а не после публикации.
Для блога это особенно удобно:
- запись остаётся обычным файлом;
- метаданные проверяются схемой;
- список страниц строится из коллекции;
- заголовки статьи доступны шаблону для автоматического оглавления;
- содержимое можно хранить рядом с кодом и проверять через Git.
Если редакторы работают только через CMS, преимущество файлового контента уменьшается, но Astro умеет получать данные и из внешних источников.
Данные в Next.js
Next.js не навязывает одну контентную модель. Можно использовать MDX, headless CMS, базу данных или собственный API. Это гибко, особенно когда публикация связана с ролями, предпросмотром, пользовательскими данными и сложным редакционным процессом.
Цена гибкости — больше решений, которые команда принимает самостоятельно: структура данных, кеширование, инвалидация, предварительный просмотр и границы клиентского кода.
Где Astro подходит лучше
Я бы начинал с Astro для следующих проектов:
- Личный или корпоративный блог.
- Документация продукта.
- Маркетинговый сайт с несколькими интерактивными блоками.
- Контентное медиа без сложного личного кабинета.
- Каталог, основная ценность которого — индексируемые страницы.
- Сайт, где важна простая статическая публикация на CDN.
Это не означает, что Astro ограничен статикой. Он поддерживает серверный рендеринг и API-маршруты. Но его архитектура помогает оставить документ документом.
Где Next.js практичнее
Next.js становится сильнее, когда проекту нужны:
- существующая дизайн-система на React;
- большая команда React-разработчиков;
- авторизация и разграничение прав;
- персонализированный интерфейс;
- серверные действия, формы и мутации данных;
- насыщенные интерактивные сценарии;
- единая платформа для сайта и веб-приложения.
Переносить зрелое React-приложение на Astro только ради уменьшения JavaScript обычно невыгодно. Сначала стоит найти реальные тяжёлые клиентские границы, исправить загрузку данных и проверить сторонние скрипты.
Стоимость поддержки
У контентного проекта есть скрытая стоимость: обновление зависимостей, понимание рендеринга, диагностика кеша и обучение новых участников.
Astro уменьшает количество концепций для простого сайта. Страница, layout, коллекция контента и несколько компонентов часто покрывают весь проект.
Next.js предлагает больше возможностей в одной системе, но требует дисциплины:
- понимать, где выполняется компонент;
- контролировать границы
"use client"; - выбирать режим кеширования;
- учитывать различия между статическим и динамическим рендерингом;
- проверять, что удобная абстракция не увеличила клиентский пакет.
Сложность оправдана, когда продукт использует эти возможности. Если нет, она превращается в операционный налог.
Как принять решение
Перед стартом я использую простой порядок.
1. Описать интерактивные сценарии
Не «на сайте будет интерактив», а конкретно: фильтр каталога, авторизация, редактор, форма, график, комментарии. Для каждого сценария полезно понять, требуется ли постоянное состояние в браузере.
2. Определить источник данных
Markdown в репозитории, CMS, база данных и пользовательский API требуют разных процессов публикации. Фреймворк должен упрощать основной поток, а не только первый прототип.
3. Проверить ограничения размещения
Статический хостинг, Node-сервер, edge runtime и корпоративная инфраструктура дают разные возможности. Этот вопрос лучше решить до выбора библиотек, связанных с конкретной средой выполнения.
4. Собрать одну реальную страницу
Прототип должен включать изображение, навигацию, форму или другой типичный интерактив, а также производственный способ загрузки данных. Пустая стартовая страница почти ничего не говорит о будущем проекте.
5. Измерить
Сравнивайте HTML, JavaScript, изображения, время сборки, доступность и удобство разработки. Оценка «ощущается быстро» полезна, но не заменяет измерения.
Что выбрано для Smooth Flow
Здесь контент хранится в типизированной коллекции, страницы собираются заранее, а JavaScript используется точечно. Такой проект совпадает с базовой моделью Astro и не требует отдельного React-runtime.
Если в будущем появится сложный кабинет автора, совместное редактирование или персонализация, решение можно пересмотреть. Фреймворк — не идентичность проекта, а текущий инженерный компромисс.