Сравнение Astro Islands vs Server Components сводится к одному вопросу: где именно в вашей архитектуре живёт JavaScript и кто решает, когда его загружать. Если сайт в основном контентный - маркетинговый лендинг, блог, каталог услуг - Astro Islands дают меньший вес страницы и быстрый TTI, потому что JS не отправляется браузеру, пока вы явно не поставите директиву client:*. Next.js Server Components выигрывают, когда сайт уже завязан на React-экосистему, а часть страниц - это интерактивные приложения, а не витрины.
В проектах миграции на headless-стек мы регулярно видим одну и ту же путаницу: команды выбирают между Astro и Next.js по названию фреймворка, а не по модели рендеринга. Разница в производительности почти всегда объясняется не самим фреймворком, а тем, как он гидратирует компоненты - весь клиентский рантайм сразу или частями по запросу.
Ниже - разбор архитектуры Islands и Server Components на уровне того, что происходит с байтами JavaScript между сервером и браузером, конкретные сценарии, где Server Islands (Astro 4.x+) выигрывают у выборочной гидратации RSC и наоборот, и цифры веса страницы и TTI для типового маркетингового сайта.
Боль ощущается на этапе аудита: PageSpeed показывает LCP на грани нормы, а вкладка Coverage в DevTools - 300+ KB неиспользуемого JavaScript на лендинге без единой формы. Для маркетингового сайта, где большая часть трафика - разовый визит с рекламы, каждый лишний килобайт JS увеличивает TTI и напрямую бьёт по конверсии на мобильных сетях.
Как Astro Islands рендерит страницу
Astro рендерит всю страницу в статический HTML на этапе сборки или на сервере и по умолчанию не отправляет в браузер ни одной строки JavaScript.
Islands architecture (островная архитектура): подход, при котором страница остаётся статическим HTML, а интерактивные компоненты гидратируются независимо друг от друга, как отдельные “острова” на статическом “океане” разметки.
Каждый компонент получает JS только если вы явно об этом попросили директивой: client:load (сразу при загрузке), client:idle (когда браузер освободился), client:visible (когда остров попал во вьюпорт) или client:media (по медиа-запросу, например только на мобильных). Если на странице 12 компонентов и интерактивны из них два - калькулятор цены и форма подписки, - JS-бандл соберётся только для этих двух островов. Остальные десять остаются чистым HTML без единого байта рантайма и без риска hydration mismatch.
Пример client:visible в Astro
---
import PricingCalculator from '../components/PricingCalculator.jsx';
---
<PricingCalculator client:visible />Отдельно стоят Server Islands - техника, которую Astro развивает с версии 4.x. Server Island откладывает рендеринг конкретного участка страницы и подгружает его отдельным запросом уже после того, как статическая часть страницы отдана браузеру, не блокируя первую отрисовку. Пока Server Island ждёт ответа сервера, на его месте показывается заранее заданный fallback - скелетон или заглушка, которая подменяется реальным содержимым без перезагрузки страницы. Подробнее о механике - в документации Astro по Server Islands.
Как Next.js Server Components рендерят страницу
Next.js по умолчанию считает каждый компонент серверным, пока вы явно не пометите его директивой 'use client'.
React Server Components (RSC): компоненты, которые рендерятся исключительно на сервере, их код никогда не попадает в клиентский бандл, а связь с интерактивными частями страницы держится через явную границу 'use client'.
Директива 'use client' определяет не сам компонент как клиентский, а точку входа: всё дерево ниже этой границы гидратируется в браузере, если только вглубь него не передан Server Component как children-проп. Подробности - в официальной документации директивы use client.
Пример 'use client' в Next.js
'use client';
export default function PricingCalculator() {
// useState, обработчики событий, доступ к window
return <div>...</div>;
}Важная деталь, которую часто упускают при выборе стека: сам факт, что часть компонентов серверные, не делает страницу нулевой по JS. Как только на странице есть хотя бы один клиентский компонент, браузер получает React-рантайм и логику гидратации для всего дерева ниже границы 'use client' - Next.js по-прежнему исходит из философии полной гидратации страницы, а выборочная гидратация (concurrent-функции React 18) работает поверх неё как оптимизация, а не как архитектура по умолчанию, в отличие от Astro, где ноль JS - это стартовая точка.
Server Islands vs выборочная гидратация RSC: где каждая архитектура выигрывает
Оба подхода решают одну и ту же задачу - не дать медленному или персонализированному фрагменту заблокировать страницу целиком, - но по-разному распределяют ответственность между сервером и клиентом.
Server Islands выигрывают там, где на иначе полностью статичной странице есть один персонализированный или динамический кусок: цена с учётом валюты пользователя, счётчик просмотров, блок “рекомендуем вам” по cookie. Server Island рендерит именно этот фрагмент на каждый запрос, а вся остальная страница остаётся статическим HTML, закэшированным на CDN. Next.js для такого же сценария обычно вынужден переводить в динамический рендеринг всю страницу или сегмент маршрута - Partial Prerendering (PPR), который решает эту проблему точечно, по состоянию на середину 2026 года остаётся экспериментальной функцией и требует включения флагом.
Выборочная гидратация RSC выигрывает, когда сайт - это не набор независимых виджетов, а связанное приложение: личный кабинет, многошаговая форма с общим состоянием, дашборд с фильтрами, которые влияют друг на друга. Здесь модель React с общим деревом компонентов, контекстом и hooks экономит архитектурную сложность - не нужно искусственно резать интерфейс на изолированные острова с раздельным состоянием и придумывать, как их синхронизировать между собой.
Практическое правило: если динамических участков на странице один-два и они не связаны друг с другом по состоянию - берите Server Islands. Если динамических участков много и они образуют единый интерфейс - выборочная гидратация RSC подойдёт лучше, потому что не потребует ручной оркестрации между изолированными островами.
Разница проявляется и в кэшировании на CDN. Статическая часть страницы с Server Island кэшируется на edge как обычный статический файл, а серверный вызов для самого острова выполняется отдельно и не сбрасывает кэш всей страницы. При Partial Prerendering в Next.js граница между статикой и динамикой определяется на уровне сегмента маршрута, а не отдельного компонента, поэтому конфигурация кэша требует больше внимания на старте проекта, особенно если несколько независимых динамических блоков соседствуют на одной странице.
Astro Islands vs Server Components: вес страницы и TTI на маркетинговом сайте
Разница в архитектуре гидратации напрямую переводится в килобайты JavaScript и секунды TTI - для рекламного трафика на мобильных сетях это не абстракция, а деньги за клик, потраченные на страницу, которая ещё не стала интерактивной.
| Сценарий | Astro Islands | Next.js (RSC + клиентские компоненты) |
|---|---|---|
| Статический лендинг без форм | 0-5 KB JS (gzip) | 70-90 KB JS (React-рантайм) |
| Лендинг с формой и FAQ-аккордеоном | 15-25 KB JS (только острова) | 90-120 KB JS |
| Блок с ценами в реальном времени (Server Island / dynamic route) | +5-10 KB на остров, статика не блокируется | сегмент или вся страница становится dynamic route, часть CDN-кэша теряется |
| TTI на среднем 4G-телефоне | 0,8-1,5 с | 2,5-4 с |
Цифры - ориентир по типовым проектам, а не гарантия: точное значение зависит от веса самих React- или Vue-компонентов внутри островов и от того, сколько данных передаётся между сервером и клиентом. Общий принцип не меняется: меньше JS в основном потоке - меньше долгих задач (long tasks) - лучше INP. Порог <200 мс для INP и то, как долгие задачи его портят, разобраны в статье про оптимизацию INP на Astro и Next.js.
Реальный кейс: миграция лендинга с Next.js на Astro
В типовом проекте миграции B2B-лендинга с Next.js (App Router, гидратация по умолчанию) на Astro с островами мы обычно видим один и тот же паттерн: JS-бандл главной страницы падает с 200-250 KB (gzip) до 25-40 KB, потому что из полутора десятков компонентов интерактивными оказываются два-три - форма заявки, карусель отзывов и FAQ-аккордеон.
LCP в таких проектах обычно улучшается с 3-3,5 секунд до 1,2-1,6 секунды на среднем мобильном устройстве - не столько за счёт самой Islands-архитектуры, сколько за счёт того, что статический HTML отдаётся сразу, без ожидания гидратации всего дерева. Это диапазон по типовым проектам, а не единичный кейс с точными цифрами: точный результат зависит от хостинга, CDN и веса медиа на странице.
Когда выбирать Astro Islands
- Сайт в основном контентный: лендинги, блог, каталог услуг, документация - страницы, где 80%+ разметки статичны.
- Приоритет - предельно быстрый TTI на мобильном трафике с платной рекламы, где каждая лишняя секунда до интерактивности снижает конверсию.
- Интерфейс собран из независимых виджетов (форма, калькулятор, карусель), а не единого связанного приложения.
- Команда выбирает Headless CMS под контент-центричный сайт - разбор вариантов есть в статье Sanity vs Contentful vs Strapi для B2B-сайта.
Когда выбирать Next.js Server Components
- Сайт - часть более крупной React-кодовой базы: личный кабинет, продуктовый дашборд, единый репозиторий с самим приложением.
- Команда уже инвестировала в React-экосистему - компоненты, hooks, внутренняя дизайн-система - и не готова дублировать её на другом фреймворке.
- Нужны вложенные layouts с общим состоянием между разделами, а не набор изолированных виджетов.
- В плане - Partial Prerendering или плотная интеграция с Vercel Edge Functions и ISR.
Для каких сайтов это решение критично
Выбор между Astro Islands и Server Components особенно важен для стартапов и SaaS-команд, которые строят маркетинговый сайт с нуля и одновременно думают о будущем продуктовом приложении. Если маркетинговый сайт и продукт будут жить в разных кодовых базах - архитектура рендеринга сайта не обязана совпадать со стеком продукта, и Astro часто выигрывает именно на этом сайте. Если планируется общий монорепозиторий с продуктом на React - выбор Next.js Server Components снимает часть архитектурных издержек на дублирование компонентов.
Для лендингов под платный трафик разница ощущается быстрее всего: чек-лист технических требований для такой страницы - в статье про технический чек-лист лендинга под платный трафик.
Часто задаваемые вопросы
В чём главное отличие Astro Islands vs Server Components?
Astro Islands по умолчанию не отправляют в браузер JavaScript вообще, пока вы явно не пометите компонент директивой client:*. Next.js Server Components уменьшают серверный код в клиентском бандле, но как только на странице появляется хотя бы один клиентский компонент, браузер получает React-рантайм и логику гидратации для всего дерева ниже границы 'use client'. Разница не в том, что RSC “менее продвинутые”, а в том, что это разные точки отсчёта: у Astro ноль JS - старт, у Next.js - оптимизация поверх модели полной гидратации.
Можно ли использовать Server Islands и клиентскую гидратацию одновременно?
Да. Server Island отвечает только за то, чтобы отложить рендеринг конкретного динамического фрагмента до отдельного серверного запроса. Внутри самого острова может быть обычный интерактивный компонент с директивой client:load или client:visible - серверная отложенная отрисовка и клиентская гидратация работают на разных уровнях и не конфликтуют друг с другом.
Next.js Server Components полностью убирают клиентский JavaScript со страницы?
Нет. RSC убирают из клиентского бандла код, который выполняется только на сервере - обращения к базе данных, секреты, тяжёлые зависимости. Но React-рантайм и логика гидратации всё равно загружаются, если на странице есть хотя бы один компонент с 'use client', а на практике на маркетинговых сайтах такой компонент есть почти всегда - форма, меню, аккордеон.
Какая архитектура лучше для Core Web Vitals на маркетинговом сайте?
Для чисто контентных страниц Astro Islands обычно даёт более низкий LCP и TTI за счёт меньшего веса JS и отсутствия гидратации там, где она не нужна. Next.js подтягивается ближе, если страница и так требует много клиентской интерактивности - тогда разница в весе сокращается, а решающим фактором становится, насколько грамотно расставлены границы 'use client' и используется ли Partial Prerendering.
Можно ли перейти с Next.js Server Components на Astro Islands без переписывания всего фронтенда?
Компоненты на React, Vue или Svelte можно переносить в Astro почти без изменений - Astro поддерживает несколько UI-фреймворков одновременно и просто оборачивает их в остров с нужной директивой гидратации. Переписать придётся роутинг, слой данных и то, как страница собирается в HTML, но сами интерактивные компоненты в большинстве случаев переиспользуются.
Что делать дальше
- Сначала посчитайте, сколько на сайте страниц действительно нуждаются в глубокой клиентской интерактивности, а сколько - витрины с одной формой.
- Если доля витринных страниц выше 70-80% - Astro Islands почти всегда дадут меньший вес и быстрый TTI без потери функциональности.
- Если сайт технически - часть продукта на React с общим состоянием между разделами, выборочная гидратация Next.js избавит от лишней архитектурной сложности.
- Не выбирайте фреймворк по названию - сравнивайте модель гидратации под конкретный набор страниц.
Если вы выбираете стек для нового маркетингового сайта или пересобираете медленный Next.js-лендинг под архитектуру островов - опишите текущую структуру страниц команде Exceltic.dev. Разберём, какие компоненты стоит оставить клиентскими, какие вынести в Server Islands, и оценим объём работ, в том числе если сайт нужно построить с нуля.