<b>Astro удобно брать не за “магический SSG”, а за границы между контентом и интерактивом</b>

<b>Astro удобно брать не за “магический SSG”, а за границы между контентом и интерактивом</b>

У него сильная сторона не в том, что он “умеет всё”, а в том, что он заставляет явно разделять: что рендерится статикой, а что должно ожить на клиенте. Для контентных сайтов, лендингов, документаций и маркетинговых витрин это часто важнее, чем один большой SPA-каркас.

Есть три проверки перед стартом:
— 80% страницы должно жить без JS;
— интерактивные острова должны быть маленькими и редкими;
— данные для сборки должны приходить из одного предсказуемого слоя, а не из пяти API подряд.

Если проект начинает расти, первым ломается не Astro, а дисциплина вокруг него: вставляют тяжелые виджеты в каждый блок, тянут клиентский код на весь экран и превращают страницу в обычный SPA с лишними накладными расходами. В этот момент выигрыша от островной архитектуры уже не видно.

Хорошая привычка: сначала собрать страницу как статический документ, потом точечно добавить формы, фильтры, поиск и счётчики. Всё, что не требует мгновенной реакции пользователя, лучше оставлять на сервере или в билде.

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