RSC, стратегия на маршрут и production-наблюдаемость

Менеджер продукта спрашивает: маркетинговая главная, страницы товаров с обновлением цен несколько раз в день, залогиненный дашборд аккаунта с медленным запросом истории заказов и флоу оформления — должны ли они все использовать одну стратегию рендеринга? Ответ — нет, и неправильный выбор стоит либо TTFB, либо свежести, либо INP, либо SEO. Правильный ответ требует решения на маршрут, понимания роли RSC и production-телеметрии, которая ловит проблемы до пользователей.

RSC и SSR — ортогональные оси. React Server Components контролируют, какие компоненты вообще доставляют JavaScript на клиент. Server Component запускается на сервере, рендерится в HTML (или RSC wire format) и вносит ноль байт в клиентский bundle — его код никогда не достигает браузера, поэтому он никогда не гидрируется. Client Component ('use client' в начале файла) отправляет код на клиент, SSR-рендерится в HTML при начальном рендере (если SSR включён), и затем гидрируется. SSR контролирует когда и где генерируется HTML — в момент запроса на сервере (SSR), на билде (SSG) или по расписанию с кэшированием (ISR). RSC контролирует сколько из этого HTML нужно сделать интерактивным. Страница, состоящая на 90% из Server Components, доставляет маленький клиентский bundle и имеет минимальную стоимость гидратации — даже при полном SSR. Распространённое заблуждение — думать, что RSC заменил SSR; это не так. Хорошо спроектированная страница использует оба: Server Components доставляют server-вычисленный HTML без клиентской стоимости, а небольшие 'use client'-острова обрабатывают реально интерактивные части.

SSR и SEO. SSR и SSG одинаково хорошо работают для SEO — оба доставляют полный HTML поисковым роботам. Разница в стоимости и свежести: SSG бесплатен на запрос (CDN-хит), SSR стоит серверного времени на каждый запрос. CSR — худший вариант для SEO: Googlebot индексирует JS-рендеренный контент, но с задержкой и менее надёжно. Streaming SSR с правильными границами Suspense аналогично хорош для SEO, поскольку shell доставляет полный HTML — медленный фрагмент ещё не прибыл, но заголовок, title и основной контент уже доступны роботу.

Фрейм решений на маршрут. Правильный подход — никогда не одна стратегия для всего приложения. Каждый маршрут имеет разные требования к свежести, потребность в интерактивности и профиль latency данных — и эти три измерения определяют стратегию:

• Маркетинговая главная — контент одинаков для всех, меняется по расписанию маркетинга (дни, не минуты). Стратегия: SSG. Отдаётся прямо с edge CDN, TTFB — десятки миллисекунд, нулевая серверная работа на запрос, и новый билд при деплое маркетинга обновляет её.

• Страницы товаров — одинаковый контент для каждого пользователя, но цены обновляются несколько раз в день, и SEO требует быстрого LCP. Стратегия: ISR с интервалом ревалидации (например, 4 часа) плюс on-demand ревалидация, триггерируемая вебхуком ценового фида. Страница — кэшированный статический документ для подавляющего большинства запросов — отличный LCP и SEO — и свежесть ограничена: ни один запрос не ждёт больше одного интервала от обновления цены.

• Дашборд аккаунта — на пользователя, должен быть свежим, но имеет один медленный запрос (история заказов). Стратегия: streaming SSR. Рендер на запрос для свежести, но обернуть запрос истории заказов в Suspense-границу. Shell и быстрые секции стримятся немедленно (~50 мс TTFB); граница истории заказов стримится, когда её запрос разрешается. Пользователь видит контент быстро; медленный запрос не блокирует его.

• Оформление заказа — на пользователя, корректность превыше всего, высокая интерактивность. Стратегия: SSR на запрос. Держать в большей степени Server Components с маленькими 'use client'-островами для полей формы и платёжных инпутов. Поверхность гидратации остаётся минимальной — только интерактивные части формы гидрируются, что держит INP низким даже под высокой нагрузкой на главный поток.

ISR на грани: кэш, инвалидация, сборка. Каждый CDN POP хранит свою собственную запись кэша. On-demand ревалидация (Next.js revalidatePath / Vercel purge API) инвалидирует запись глобально — но есть краткое окно (секунды до десятков секунд), в течение которого одни POPs отдают старую версию, а другие — новую. Для цено-чувствительных страниц ограниченная протухлость ISR — осознанный компромисс: все POPs протухают не более чем на один интервал, а on-demand ревалидация — клапан сброса давления. Если требуется истинная согласованность по всем POPs в момент обновления — единственный вариант это полный SSR на запрос.

Минимизация стоимости гидратации по всем маршрутам. Универсальный принцип: толкать 'use client' как можно ниже по дереву компонентов. Layout-компонент, карточка, таблица данных — почти всегда Server Components. Только лист, которому реально нужен onClick, useState или browser API, должен быть Client Component. Когда 'use client' вытолкнут к листьям, клиентский bundle сжимается, проход гидратации крошечный, и INP уверенно остаётся под 200 мс.

Production-наблюдаемость. Стратегия рендеринга работает только тогда, когда вы знаете, когда она ломается. Три категории сигналов:

1. TTFB и LCP на маршрут — SSG-маршруты должны иметь TTFB под 50 мс от CDN-хитов; streaming SSR-маршруты должны сбрасывать shell за ~50–100 мс. LCP должен быть под 2,5 с при p75. Детектируется в field data (CrUX) и синтетическом мониторинге (Lighthouse CI).

2. INP на страницу — длинная задача гидратации — наиболее частая INP-регрессия. Если INP при p75 превышает 200 мс на странице, недавно получившей Client Component или увеличившей размер bundle, стоимость гидратации выросла. Коррелируйте с изменениями кода. RUM-инструменты сегментируют INP по страницам.

3. Частота hydration mismatch — React логирует предупреждения о несоответствии в разработке, но в продакшне молчит, если не инструментировать. Подключите window.addEventListener('error', ...) для перехвата отчётов React error boundary, или используйте framework-интеграцию (Next.js instrumentation.ts, Sentry React plugin), захватывающую ошибки гидратации и отправляющую в трекер ошибок. CI-гейт: ноль новых ошибок hydration-mismatch на деплой — несоответствие в продакшне означает CLS-событие плюс recovery re-render.