Rendering‑стратегии в Front‑end: CSR, SSR, Universal, SSG и Prerendering

Client‑Side Rendering (CSR)

При клиентском рендеринге сервер отдает лишь пустой HTML‑шаблон и набор JavaScript‑файлов. Браузер загружает скрипты, исполняет их, создает виртуальное дерево компонентов, запрашивает данные через API и только после этого формирует DOM.

Последовательность запросов

1. GET /app → сервер отвечает минимальным HTML (<div id="root"></div>).
2. Браузер обнаруживает <script src="bundle.js"> и запрашивает JavaScript‑пакет.
3. После загрузки скриптов фреймворк инициализируется, монтирует корневой компонент и отправляет API‑запросы.
4. Получив JSON‑ответ, приложение рендерит пользовательский интерфейс.

Плюсы

• Низкая нагрузка на сервер – сервер обслуживает только статические файлы.
• Простая кэшируемость – весь бандл можно разместить в CDN.
• Быстрая интерактивность после загрузки – время до первой интерактивной отрисовки (TTI) совпадает с первой значимой отрисовкой (FMP).

Минусы

• Значительная задержка первого кадра – пользователь видит пустой экран или спиннер до загрузки и выполнения JS.
• Плохая SEO – поисковые боты часто не исполняют JavaScript, поэтому индексация контента ограничена.

Кейсы применения
Инструменты с высокой интерактивностью (дашборды, редакторы, графические конструкторы) и приложения, требующие авторизации, где SEO не критично.

Server‑Side Rendering (SSR)

SSR генерирует готовый HTML на сервере, отправляя клиенту полностью сформированную страницу. После первой отрисовки браузер «гидратирует» её, привязывая интерактивный JavaScript.

Последовательность запросов

1. GET /page → сервер собирает данные, рендерит React/Vue‑компоненты в строку HTML и отправляет её клиенту.
2. Браузер сразу получает готовый DOM и отображает контент.
3. Параллельно загружается JavaScript‑бандл, который «гидратирует» страницу, делая её интерактивной.

Плюсы

• Мгновенный первый контент – пользователь видит готовый UI без ожидания JS.
• Хорошая SEO – поисковые системы индексируют полностью сформированный HTML.
• Уменьшение времени до первой отрисовки (First Contentful Paint).

Минусы

• Больше нагрузки на сервер – каждый запрос требует выполнения рендеринга и, зачастую, обращения к базе данных.
• Сложнее кэшировать – динамический HTML трудно хранить в CDN без дополнительных механизмов.

Кейсы применения
Контентные сайты, маркетинговые лендинги, e‑commerce‑страницы, где важна быстрая индексация и первое визуальное представление.

Universal (Isomorphic) Rendering

Универсальная архитектура объединяет преимущества CSR и SSR: сервер генерирует HTML, а клиент продолжает работу в режиме SPA.

Поток выполнения

1. При первом запросе сервер рендерит страницу (SSR) и передаёт сериализованные данные (window.__INITIAL_STATE__).
2. Браузер отображает готовый HTML и сразу начинает загрузку клиентского бандла.
3. После загрузки бандла происходит гидратация, и приложение переходит в полностью клиентский режим, позволяя навигацию без перезагрузки.

Плюсы

• Быстрый First Paint + полноценная SPA‑навигация.
• SEO‑дружелюбность и меньшая нагрузка после первой отрисовки.

Минусы

• Сложность реализации – требуется синхронизация состояния между сервером и клиентом, настройка сборки для двух окружений.
• Увеличенный размер бандла – в него включаются и серверные, и клиентские части.

Кейсы применения
Большие веб‑приложения, где важна SEO, но также требуется интерактивность, например новостные порталы с пользовательскими панелями.

Static Site Generation (SSG)

SSG генерирует полностью готовый набор HTML‑файлов во время сборки проекта. После деплоя каждый запрос обслуживается статическим файлом, а клиентский JavaScript добавляет интерактивность.

Процесс

1. На этапе сборки (npm run build) фреймворк исполняет каждый роут, получает данные (через API или локальные файлы) и сохраняет результат в виде HTML.
2. При запросе /about сервер просто отдает about.html.
3. Браузер загружает JS‑бандл, который «гидратирует» страницу.

Плюсы

• Максимальная производительность – статические файлы обслуживаются CDN с микросекундной задержкой.
• Отличная SEO – готовый HTML доступен сразу.
• Низкая стоимость хостинга – отсутствие серверных вычислений.

Минусы

• Ограниченная динамика – изменения контента требуют пересборки сайта.
• Сложность с часто меняющимися данными – требуется интеграция с клиентскими запросами или ISR (Incremental Static Regeneration).

Кейсы применения
Блоги, документация, маркетинговые сайты, портфолио, где контент меняется редко.

Prerendering

Prerendering — гибридный подход, когда серверный сервис (например, Puppeteer) рендерит страницу в браузерном окружении и сохраняет полученный HTML. Это решение часто используется для одностраничных приложений, которые изначально написаны как SPA, но нуждаются в SEO‑доступе.

Схема работы

1. При деплое запрос к /product/123 обрабатывается скриптом‑рендерером, который открывает страницу в headless‑браузере, ждёт загрузки данных и сохраняет готовый HTML в кэш.
2. При последующих запросах клиент получает уже сгенерированный HTML, а затем загружает обычный JS‑бандл.

Плюсы

• Не требует изменения кода приложения – работает поверх существующего CSR‑проекта.
• SEO‑совместимость без полной миграции на SSR.

Минусы

• Время генерации при первом запросе может быть высоким.
• Не подходит для часто обновляемого контента без автоматической пере‑пререндеринга.

Кейсы применения
Одностраничные маркетинговые проекты, где команда хочет сохранить SPA‑архитектуру, но требуется индексировать страницы поисковиками.

Как выбрать оптимальную стратегию

Решающее дерево выбора

1. Требуется ли SEO? – если нет → CSR.
2. Нужно быстрое первое отображение и SEO? – SSR или Universal.
3. Контент статичен и обновляется редко? – SSG.
4. Есть готовое SPA, но нужен SEO без полной миграции? – Prerendering.

Выбор рендеринга определяется компромиссом между производительностью, нагрузкой на сервер и потребностями в индексации. Правильное сочетание стратегий (например, SSG для публичных страниц и CSR для защищённого кабинета) позволяет построить гибкую и масштабируемую архитектуру фронтенда.