<b>Server Components — не ускоритель “по умолчанию”, а инструмент для точечного среза JS</b>

<b>Server Components — не ускоритель “по умолчанию”, а инструмент для точечного среза JS</b>

Server Components в React/Next.js часто продают как универсальный способ сделать сайт быстрее. На практике это не замена всем клиентским компонентам, а способ убрать лишний JavaScript с тех мест, где интерактивность не нужна.

Полезная рамка простая:
— всё, что только читает данные и рендерит HTML, кандидат в server component;
— всё, где есть state, эффекты, браузерные API, события — остаётся на клиенте;
— чем выше в дереве компонент, тем дороже ошибка: один лишний <code>"use client"</code> может протащить клиентский бандл вниз по ветке.

Есть наблюдение которое стоит проверить: многие команды ломают архитектуру не RSC, а смешением ответственности. Когда fetch, форматирование, access control и интерактивность живут в одном месте, серверный рендер теряет смысл. Разделяйте слой получения данных и слой поведения.

Ещё один частый промах — думать только про “меньше JS”. У Server Components есть цена: сложнее дебажить границы, тяжелее переносить старые паттерны, и не все UI-киты спокойно живут в таком режиме. Если библиотека завязана на контекст, refs или эффектную инициализацию, её нельзя бездумно тащить в серверное дерево.

Проверка перед внедрением:
— есть ли в этом блоке реальная интерактивность;
— нужен ли ему доступ к секретам, cookies, server-only данным;
— не раздувает ли <code>"use client"</code> соседние компоненты;
— не проще ли оставить компонент обычным и выиграть в читаемости.

RSC дают сильный выигрыш, когда их используют как нож, а не как идеологию.