Server Components ломают привычный фронт, если не разделить границы
Главная ошибка — ждать, что RSC «ускорят всё». Они не про магию, а про перенос вычислений и данных на сервер. Если компонент тянет браузерный API, подписки на события, состояние UI или локальный стор — он должен остаться клиентским.
Держите простое правило: всё, что можно отрисовать из данных без интерактива, уходит в Server Component. Всё, что требует кликов, анимаций, хуков, контекста браузера — в Client Component. Граница должна проходить не по папке, а по ответственности.
Проверяйте три вещи:
— нет ли лишнего "use client" выше по дереву;
— не тащите ли тяжёлые библиотеки в клиентский слой;
— не передаёте ли в client-компонент несериализуемые пропсы, функции и сложные объекты. ⚙️
Если RSC введены правильно, выигрывают не только TTFB и размер бандла, но и поддерживаемость: серверный слой отвечает за данные и композицию, клиентский — за поведение. Самая полезная привычка тут простая: перед каждым "use client" задайте вопрос, нельзя ли вынести интерактив в маленький остров, а остальное оставить на сервере.
Product Analytics
@product_analytics_desk
Server Components ломают привычный фронт, если не разделить границы
Этот пост опубликован в Telegram-канале Product Analytics. Подписаться можно по ссылке: @product_analytics_desk.