Андрей Викулов (VProger)

Posted on Jan 31 • Originally published at viku-lov.ru on Jan 31

Astro vs React/Vue и SSG: когда Astro — перебор, а когда спасение

#astro #react #vue #nextjs

Astro vs React/Vue и SSG: когда Astro — перебор

Выбор стека для фронта в 2026 году часто выглядит так: либо «берём Next/Nuxt и едем», либо «делаем всё на чистом SSG», либо «Astro, потому что islands». А потом выясняется, что проекту нужна не «идеальная архитектура», а быстрое время до релиза , понятное сопровождение и предсказуемая стоимость изменений.

Ниже — практичная аналитика: когда Astro реально даёт выигрыш , а когда это лишний слой, который вы будете объяснять следующему разработчику по понедельникам.

Для контекста: часть мыслей пересекается с моими разборками по Astro и SEO в серии статей — можно начать с этих материалов:

Astro 2025–2026, часть 1: структура, MDX, Content Collections, часть 2: islands, View Transitions, SEO, sitemap, RSS.

Карта местности: что мы вообще сравниваем

SSG (простая статика)

Hugo / Eleventy / Jekyll / чистый Astro без интерактива / любой генератор

Генерируем HTML на этапе сборки.
Деплой — CDN или статический хостинг.
Клиентского JS — минимум.

Пример страницы в чистом Astro (без островков — только HTML):


---

// src/pages/about.astro — обычная статическая страница

---

<html lang="ru">

<head>

<title>О проекте</title>

</head>

<body>

# О проекте

Контент отрендерится в HTML при сборке. Никакого клиентского JS.

</body>

</html>

Astro (content-first + islands)

По умолчанию генерирует HTML как SSG.
Интерактив — точечно , через islands (React/Vue/Svelte/Solid — что нравится).
Главная идея: _«JS только там, где он реально нужен»_.

Минимальный пример страницы с одним островком:


---

// src/pages/docs.astro

import Counter from "../components/Counter.tsx";

---

<Layout>

# Документация

Весь текст — статический HTML. Кнопка ниже — островок React.

<Counter client:load />

</Layout>

Next.js / Nuxt (app-first)

SSR/SSG/ISR/Server Actions/edge — целая платформа.
Отлично для приложений и сложной интерактивности.
Цена: больше runtime-сложности и больше «магии фреймворка».

Когда Astro реально выигрывает

1) «Статика с островками» — его родная среда

Если 80–95% контента — это читаемый HTML : статьи, лендинги, справка, документация, каталог с карточками, страницы услуг — Astro почти всегда уместен.

Почему получается быстрее:

меньше клиентского JS → меньше времени на parse/compile/execute в браузере;
проще попасть в хорошие метрики (LCP, INP, CLS) без героизма;
SEO «естественное»: контент уже в HTML.

2) SEO важно, а редакторский контент — основной актив

Если проект живёт на поисковом трафике, Astro помогает не мешать самому себе:

меньше «гидратационной лапши»;
меньше случайных регрессий производительности;
проще держать дисциплину: _интерактив только по факту необходимости_.

3) Нужно «подмешать» UI-виджеты без превращения в SPA

Типовой кейс: маркетинг-сайт + калькулятор + форма + фильтры + мини-галерея.

Astro позволяет не тащить весь SPA-рантайм на каждую страницу.

Пример: виджет на React только там, где нужен:


---

// src/pages/pricing.astro

import PricingCalc from "../components/PricingCalc.tsx";

---

<section>

## Калькулятор стоимости

<!-- Гидратация только по событию -->

<PricingCalc client:visible />

</section>

4) Команде важна «простая статика», но хочется современного DX

Astro обычно проще «вкатить» в контент-команду, чем Next/Nuxt, если:

много MDX/контент-коллекций;
нужен быстрый билд и простой деплой;
интерактив ограничен и управляем.

Когда Astro — перебор (и лучше взять Next/Nuxt или SPA)

1) Проект — это приложение, а не сайт

Если у вас:

авторизация на каждой странице,
реальные кабинеты,
real-time (чаты, live-дашборды),
много состояния, ролей, сложных форм,
«почти всё интерактивное»

…то Astro будет выглядеть как обходные манёвры : островков станет много, и вы придёте к «SPA, только хуже» (потому что SPA уже решает эти задачи системно).

Здесь честнее: Next.js или Nuxt.

2) Нужны сильные app-фичи «из коробки»

Например:

продуманная модель роутинга + middleware;
серверные действия/мутации + кэш/инвалидация;
встроенная story про auth, data fetching, edge, streaming;
зрелая экосистема «всё готово».

Astro может, но чаще через сборку: отдельно API, отдельно auth, отдельно SSR-слои, отдельно кэш. Это нормально, если вы DevOps-злые. Но если задача — быстро собрать продукт, Next/Nuxt экономят время.

3) Команде важен единый «фреймворк-контракт», меньше решений

Astro даёт свободу: _«выбирай сам»_.

Свобода в продакшене — это иногда долг : больше вариантов, больше разнобоя, больше «а почему тут так, а тут иначе».

Если команда большая/разнородная — платформенные фреймворки часто проще стандартизировать.

Trade-offs по-честному

1) Сложность

SSG : минимальная сложность, но меньше интерактива и гибкости.
Astro : средняя сложность (сборка + islands + контент), но контроль над JS.
Next/Nuxt : высокая сложность, зато много готовых решений для app-кейсов.

2) Экосистема и «готовые ответы»

Next/Nuxt выигрывают по количеству «копипаст-решений» (auth, caching, patterns).
Astro выигрывает, если вы строите content-first продукт: меньше лишнего.

3) Время разработки (TTM)

Если сайт контентный: Astro часто быстрее , потому что проще держать скорость и SEO.
Если приложение интерактивное: Next/Nuxt быстрее , потому что не нужно изобретать платформу вокруг.

4) Масштабирование (scaling)

Тут важное уточнение: «скейл» бывает разный.

Скейл по трафику (CDN, статика): SSG/Astro — отлично.

Скейл по фичам приложения: Next/Nuxt — чаще предсказуемее.

Скейл команды: чем больше «правил и контрактов», тем меньше хаоса. Тут Next/Nuxt часто проще.

Практическое правило 80/20: «сколько у вас интерактива?»

Вот быстрый тест:

Если >70% страниц — читаемый контент (текст/карточки/лендинги), интерактив точечный → Astro/SSG.
Если >70% экранов — интерактивные формы, состояние, кабинет, real-time → Next/Nuxt.
Если «пополам» → обычно решает: _SEO-важность + команда + сроки_.

Чек-лист: какой стек выбрать для…

Блог / документация / контент-портал

Выбор: SSG или Astro

Astro — если нужны islands (поиск, фильтры, виджеты, комменты).
Чистый SSG — если интерактива почти нет.

Маркетинг-сайт / лендинги / сайт услуг

Выбор: Astro (или SSG)

минимальный JS, высокая скорость, простой деплой.
если нужны A/B, формы, аналитика — всё влезет островками.

Каталог товаров (без тяжёлого кабинета)

Выбор: Astro + islands или Next/Nuxt (по ситуации)

если каталог в основном читаемый + фильтры → Astro.
если личный кабинет, история заказов, персонализация повсюду → Next/Nuxt.

SPA-продукт / личный кабинет / админка

Выбор: React/Vue SPA или Next/Nuxt

«админка внутри компании» часто быстрее как SPA (Vite + React/Vue) + API.
если нужна SSR-история, deep-linking, сложная платформа → Next/Nuxt.

Real-time дашборды / чаты / тяжёлый UI

Выбор: Next/Nuxt или SPA

Astro здесь почти всегда будет «не туда»: островки размножатся и вы сами себе поставите ловушку.

Мини-матрица решений (быстро в табличку)

| ------------------------------------ | -----: | -----: | -----------------: |

| Максимальная скорость «по умолчанию» | ✅✅✅ | ✅✅✅ | ✅✅ |

| SEO из коробки | ✅✅✅ | ✅✅✅ | ✅✅✅ |

| Сложный интерактив повсюду | ❌ | ⚠️ | ✅✅✅ |

| Быстрый старт контентного проекта | ✅✅✅ | ✅✅✅ | ✅✅ |

| Быстрый старт приложения | ⚠️ | ⚠️ | ✅✅✅ |

| Контроль над клиентским JS | ✅✅✅ | ✅✅✅ | ✅ (нужно следить) |

| «Один фреймворк решает всё» | ❌ | ⚠️ | ✅✅✅ |

Примеры «как выглядит подход» (в коде)

1) Astro: интерактив только там, где нужно


---

import SearchWidget from "../components/SearchWidget.vue";

---

# База знаний

90% страницы — контент. Поиск — островок.

<SearchWidget client:idle />

2) Next/Nuxt: приложение, где данные и мутации — повсюду

Псевдокод логики «app-first» (смысл — в постоянном data flow):


// app/profile/page.tsx — серверный компонент по умолчанию

async function ProfilePage() {

const session = await getServerSession();

const user = await db.user.findUnique({ where: { id: session.userId } });

return (

<>

# Профиль

<ProfileForm user={user} />

</>

);

}

// app/actions/profile.ts — Server Action

"use server";

export async function updateProfile(data: ProfilePayload) {

await db.user.update({ where: { id: data.userId }, data });

revalidatePath("/profile");

}

Клиентский компонент ProfileForm вызывает updateProfile — кэш, инвалидация, права уже «встроены» в платформу.

3) SPA (Vite): админка без лишней платформы

Если это «внутренняя панель», где SEO не важно — часто идеально:


// vite + react/vue: максимум контроля, минимум лишнего

// роутинг, стор, запросы — ровно то, что нужно проекту

(Да, это выглядит скучно. Скучный прод — это комплимент.)

4) Директивы гидратации Astro: когда подключать JS

На практике важно не размножать островки. Кратко по директивам:

| Директива | Когда использовать |

|-----------------|---------------------|

| client:load | Сразу при загрузке страницы (критичный интерактив). |

| client:idle | После requestIdleCallback — когда браузер свободен. |

| client:visible| Когда компонент попал в viewport (например, калькулятор ниже первого экрана). |

| client:media | По медиа-запросу (виджет только на десктопе и т.п.). |

Пример: форма в футере не должна тянуть JS до скролла — используйте client:visible.

«Gap в контент-поле»: чего не хватает в обсуждении Astro/Next/Nuxt

Почти весь контент про выбор стека — это либо:

фанатские баталии,
либо сравнение бенчмарков в вакууме.

А реальный gap — вот он:

Стоимость изменений через 6 месяцев (а не скорость первого релиза).
Дисциплина клиентского JS (кто реально будет следить, чтобы «островки не размножались»?).
Кадровая реальность : кого проще нанять/заменить под ваш стек.
Платформенные зависимости : где будет жить runtime, как дебажить прод, как катать деплои.

Если ответов нет — выбор «самого модного» фреймворка превращается в лотерею с красивым README.

Итог: быстрый выбор без философии