Astro Islands vs React Server Components

Когда я объясняю стажёрам разницу между Astro Islands и React Server Components, всегда сначала приходится разобраться, на каком уровне абстракции мы вообще сравниваем. Это разные модели рендера, и сравнивать их «в лоб» как фичи фреймворков — путаница. Расскажу так, как это видится человеку, который последний год гоняет оба подхода в проде.

Что такое Astro Islands

Идея Astro: страница — это плоский HTML, в который точечно вставлены интерактивные «острова». Остров — это компонент (React, Vue, Svelte, Solid), помеченный директивой client:*. Браузер получает обычный HTML, и только остров на нужном условии (idle, visible, load, media) гидрируется и оживает.

---
import Counter from '../components/Counter.tsx';
---
<article>
  <h1>Заголовок</h1>
  <p>Длинный текст без интерактива...</p>
  <Counter client:visible />
</article>

Главное здесь — выбор. Ты не получаешь ни одного килобайта рантайма React, пока сам не попросишь.

Что такое React Server Components

RSC — это модель рендера, в которой компоненты делятся на серверные и клиентские. Серверные исполняются на сервере и сериализуются в особый формат (RSC payload), который клиент получает и собирает вместе с клиентскими компонентами в общее дерево.

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

export default async function Page() {
  const data = await fetchData();
  return (
    <article>
      <h1>{data.title}</h1>
      <p>{data.body}</p>
      <Counter />
    </article>
  );
}

// Counter.tsx
'use client';
import { useState } from 'react';
export default function Counter() {
  const [n, setN] = useState(0);
  return <button onClick={() => setN(n + 1)}>{n}</button>;
}

В этом мире сервер занимается данными и отдачей, клиент — интерактивом. Серверные компоненты не попадают в клиентский бандл, но всё дерево живёт в одной системе типов и общего React-рантайма.

Где острова выигрывают

Если у тебя в основном статический контент, Astro выкатывает страницы с минимальным или нулевым клиентским JS. Это особенно заметно на лендингах и блогах.

Я мерил на прод-проекте: страница со статьёй на Astro отдала 0 КБ JS, на Next.js c RSC и одной кнопкой подписки — 95 КБ gzip. Разница в восемь раз. Это не «недостаток» React, это просто его архитектура: рантайм нужен в любом случае.

Где RSC выигрывают

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

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

Производительность

На простых страницах Astro ощутимо быстрее по объёму JS, FCP и общему «вес страницы». На сложных формах с серверной валидацией RSC выигрывают за счёт встроенного Suspense streaming — пользователь видит первые блоки контента раньше, чем готова вся страница.

В измерениях, которые я гонял в одной и той же сети, разница между Astro Islands и Next + RSC на простой странице — около 40–60 мс в FCP. На сложной — RSC начинают показывать UI раньше за счёт стриминга, но «полностью готов» бывают позже.

Сложность ментальной модели

Astro — приземлённее. Ты понимаешь, что HTML собирается на сервере, а интерактивные острова грузятся отдельно. Ошибаться сложно: либо у компонента есть client:* и он живой, либо нет — и он статика.

RSC требует постоянно держать в голове, на каком уровне ты сейчас работаешь. Серверный компонент не может импортировать клиентский без правил, useState нельзя позвать на сервере, эффекты не работают на сервере, контекст пробрасывается особым образом. Это всё логично, но в команде с разным опытом эта граница регулярно «протекает» — и появляются странные баги вроде «пропали данные после ревалидации».

Сериализация

Серверные компоненты в RSC сериализуют пропсы. Если ты пытаешься отдать функцию или класс — получишь ошибку. В Astro Islands ты тоже передаёшь только данные, но сама модель проще — остров получает пропсы как обычные значения, без фантазий с RSC payload.

В RSC встретишь странные кейсы: даты подавать через ISO-строку, потому что иначе на клиенте они станут строками после сериализации. С Map и Set осторожно. Ничего сверхъестественного, но из-за этого код пишется чуть аккуратнее.

Серверные действия

В RSC они интегрированы как 'use server'-функции, которые можно вызывать из клиентских компонентов. Очень удобно: пишешь функцию, кидаешь её в форму, получаешь типизированный поток.

В Astro есть свой defineAction — действия, которые можно дёргать из .astro-страниц и клиентских островов. Эргономика разная, но базовый сценарий «отправить форму на сервер и обработать ответ» закрыт в обоих стеках.

Что выбирать

Если у тебя контент-сайт, документация или промо-страница — Astro Islands. Минимум рантайма, простая ментальная модель, прекрасный SEO, и React-острова доступны там, где они реально нужны.

Если у тебя полноценное продуктовое приложение, где данные на каждой странице тянут стейт, формы, мутации, авторизацию, дашборды — RSC. Они для этого и созданы, и здесь Astro будет постоянно сопротивляться, потому что предполагает, что страница — это в первую очередь контент.

Гибрид

На больших проектах разделение «контент / приложение» работает на уровне инфраструктуры. Документация и блог — Astro, продукт — Next с RSC. Ставится на одном домене с разделением по подпути, делятся стилями и компонентами через монорепо.

Этот вариант хорош тем, что каждый стек делает то, что у него получается лучше всего, и у команды нет соблазна «прокинуть RSC в блог» или «уместить дашборд в островах».

В сухом остатке

Astro Islands и React Server Components — два рабочих ответа на вопрос «как уменьшить количество JS, который мы шлём на клиент». Они решают эту задачу по-разному, и в 2026 году у каждого ярко выраженная ниша. Если выбираешь между ними и не можешь определиться — посмотри, какой код будет составлять 80% твоего проекта. Если статья или продукт — выбор очевиден без сравнений.