SSG, SSR, ISR, streaming и RSC — как работает каждая стратегия

Цена на странице товара меняется дважды в день. Залогиненный дашборд разный для каждого пользователя. Пост блога одинаков для всех. Эти три факта подразумевают три разные стратегии рендеринга — и выбор неправильной означает платить за серверные вычисления на каждый запрос, когда хватило бы попадания в кеш CDN, или отдавать протухшую цену 12 часов, когда ISR мог бы ограничить протухлость одним часом.

SSG: рендер на билде. Static Site Generation гоняет компоненты один раз во время билда и пишет результат в HTML-файлы, деплоящиеся на CDN. Путь запроса непобедим — никаких серверных вычислений, попадание в edge-кеш, time-to-first-byte в десятках миллисекунд. Цена — свежесть и масштаб: контент заморожен на момент билда, и сайт на миллион страниц билдится долго. SSG — правильный дефолт для всего, чей контент не меняется на запрос и на пользователя: маркетинговые страницы, документация, посты блога. В момент, когда страница должна отражать «сейчас» или «именно этого пользователя», чистый SSG ломается.

SSR: рендер на запрос. Server-Side Rendering гоняет компоненты на сервере на каждый запрос, производя свежий HTML каждый раз. Он может читать куки пользователя, текущее время, живые данные — HTML точно правильный для этого запроса. Цена — на критическом пути: time-to-first-byte пользователя теперь включает время серверного рендера плюс загрузку данных. Медленный запрос к базе в рендере — медленный TTFB для пользователя. SSR правилен, когда страница реально должна быть свежей на запрос или персонализированной: залогиненный дашборд, лента, результаты поиска.

ISR: SSG, обновляющий себя. Incremental Static Regeneration — SSG с правилом ревалидации. Страница отдаётся статически из кеша, но после настроенного времени — или по явному on-demand триггеру — следующий запрос получает протухшую копию, пока сервер регенерирует свежую в фоне; последующие запросы получают новую. Это stale-while-revalidate, применённый к целым страницам. ISR — ответ на «большей частью статично, но контент всё же меняется — страница товара, чья цена обновляется несколько раз в день». Мгновенная доставка SSG для подавляющего большинства запросов и ограниченная протухлость вместо полного ребилда.

Streaming SSR: отправка HTML кусками. У обычного SSR есть блокирующий изъян: сервер должен закончить рендер всей страницы — включая самую медленную загрузку данных — до того, как сможет отправить хоть один байт. Если одному виджету нужен запрос на 400 мс, каждый пользователь ждёт 400 мс на time-to-first-byte. Streaming SSR это чинит. С renderToPipeableStream сервер шлёт оболочку немедленно, и каждая граница <Suspense> стримится по мере резолва её данных. Пользователь видит шапку, навигацию и лейаут за ~50 мс; медленный виджет приходит на 400 мс позже как стримленный кусок. TTFB падает до скорости самой быстрой части страницы.

React Server Components: компоненты, никогда не уходящие на клиент. RSC — совсем другая ось. Server Component гоняется только на сервере — его код никогда не шлётся в браузер. Он может читать базу напрямую, использовать серверные секреты и импортировать тяжёлые библиотеки (markdown-парсер, подсветку синтаксиса), которые ничего не стоят клиенту, потому что никогда не пересекают провод. Его выход — не HTML и не JS-бандл, а специальный сериализованный формат, RSC payload, описывающий отрендеренное дерево. Client Components (помеченные 'use client') — интерактивные острова внутри дерева; только их код шлётся. Выигрыш — размер бандла: части приложения, которые просто «показывают серверные данные», несут ноль клиентского JavaScript.