Server Components в продакшене — где помогают, где мешают

React Server Components вышли в стабильный канал ещё в 2024, и сейчас под нагрузкой их крутят сотни команд. Обещали: меньше JS на клиенте, прямой доступ к БД из компонента, бесплатный streaming. Получили: новую модель ментальную, странные баги с гидратацией и «Client/Server boundary» в голове разработчика. Разбираем по сценариям, где RSC реально окупаются, а где Next.js Pages Router (или Remix/Astro) остаётся правильным выбором.

Что RSC на самом деле меняют

• Компонент по умолчанию серверный. Рендерится на сервере, в браузер летит готовый HTML и сериализованный «дерево» RSC payload. JS-бандла за этим компонентом нет вообще.
• Прямой доступ к БД / файлам / секретам. Сервер-компонент может сделать await db.query(...) без API-слоя. Удобно для контентных страниц.
• Граница Client / Server. Хочешь интерактив (useState, onClick, useEffect) — пометь 'use client' и компонент уходит в клиентский бандл со всеми зависимостями.
• Streaming + Suspense. Сервер начинает отдавать HTML, не дожидаясь всех данных. Шапка показывается, тело подгружается.

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

• Контентные сайты. Блог, новости, документация, маркетинг. Размер JS-бандла снижается на 40–70% против Pages Router. LCP падает.
• Data-heavy дашборды. Когда страница — это таблицы и графики, рендерящиеся на сервере, а интерактив локальный (фильтры, сортировки в client-комп). Конкретный пример: список заказов с фильтрами — таблица RSC, фильтры client, никаких API-вызовов с фронта.
• SEO + персонализация. Сервер видит куки → рендерит в HTML персонализированную ленту, поисковики получают полный контент.
• Многоязычные сайты. Тяжёлые i18n-словари остаются на сервере, в браузер не летят.
• Стриминг для «тяжёлых хвостов». Шапка + структура за 200 мс, остальное — постепенно. TTFB лучше, чем у SSR с ожиданием всех данных.

Где RSC мешают

• Высоко-интерактивные приложения. Если каждый второй компонент — 'use client', то модель просто превращается в обычный SPA + лишний слой сериализации. Канбан-доски, чаты, графические редакторы — оставайтесь на Pages Router или классическом SPA.
• Старый стейт-менеджмент. Redux, MobX, Zustand жили на клиенте. RSC не отменили их, но добавили слой «как пробросить серверные данные в клиентский стор». Обычно — через props или server actions.
• Сторонние библиотеки без поддержки. styled-components, antd до недавнего времени ломались на RSC. В 2026 большинство адаптировались, но всегда проверяйте.
• Сложность дебага. Ошибка из server-компонента отдаётся в виде «Error in RSC payload». Стек — на сервере, в браузере — таинственное «Failed to load».
• Edge-кэш. RSC и Vercel / Cloudflare edge работают, но кэш-ключи усложняются: cookies, search params, headers — всё влияет.

Граница Client / Server — главная боль

Правило: компонент, помеченный 'use client', всё дерево его импортов уходит в клиентский бандл. Импортнул иконку из тяжёлой библиотеки — потащил её всю.

Типовые ошибки:

• Сделали лейаут client-компонентом «потому что в нём dark-mode toggle». Получили SPA-стайл — никакого RSC-эффекта. Решение: вынести toggle в отдельный 'use client', лейаут оставить server.
• Пробросили данные через props в client. Всё, что в props, сериализуется в RSC payload и улетает в браузер. Не пихать туда секреты и тяжёлые объекты.
• В client-компоненте делают fetch, хотя данные уже есть на сервере. Решение: server-компонент-обёртка получает данные и отдаёт client-компоненту через props.

Server Actions — вторая большая фича

Серверная функция, вызываемая из формы или onClick на клиенте. Под капотом — RPC с сериализацией. Удобно для форм, удалений, простых мутаций без отдельного API-слоя.

Грабли:

• Любые input должны быть валидированы как «не доверяемые», даже если в форме нет лишних полей. Сервер-action — это публичный endpoint.
• Server actions не кэшируются — каждый вызов идёт на сервер.
• В случае ошибки UI показывает её через try/catch + useState — без библиотек обработки получается рукодельно.

Пропускная способность и cost

RSC снижает компьют на клиенте, увеличивает на сервере. Edge-функция считает рендер каждой странице. На большом трафике (1М+ запросов/день) это деньги: $200–800/мес против $0 при чистом SSG. Для бизнес-сайтов незаметно, для медиа-портала — пересчитывайте.

Куда RSC не идут

• Чистый SSG без интерактива. Astro / Eleventy дешевле, проще, без любой гидратации.
• Сложные SPA с многоэкранным стейтом. Vite + React Router 7 + zustand — всё ещё лучший выбор.
• Mobile-first + offline-first PWA. RSC не подходят к offline (сервер не доступен). Тут react-router data + IndexedDB.

Чеклист выбора

1. Страница в основном контент / данные с сервера, интерактива мало → RSC выигрывает.
2. Страница — это интерактивный экран, везде стейт и анимации → Pages Router или SPA.
3. Команда новая в Next.js → начинать с Pages Router, RSC учить отдельно.
4. Нужно поднять Lighthouse Performance с 60 до 90 на контентных страницах → RSC даёт самый быстрый путь.
5. Стек RU: Yandex.Cloud Functions, Cloud.ru, Selectel — RSC через Next.js standalone работает в Docker.

Итог: RSC не «новая лучшая модель», а инструмент для класса задач. Помогают на контентных и data-heavy экранах, экономят килобайты JS. Мешают там, где SPA-механика естественнее. Главный совет — не пытаться переписать всё приложение, а вводить RSC на новых страницах и смотреть метрики.