Главная · Frontend
Frontend

SSR CSR SSG и ISR: какой подход подходит вашему проекту

3DH.su3DH.su 7 июня 2026 5 мин чтения
SSR CSR SSG и ISR: какой подход подходит вашему проекту

Когда мы начинаем новый проект на современном JS-фреймворке (будь то Next.js, Nuxt или Remix), один из первых и самых критических вопросов, который встает перед архитектором: «Где именно будет генерироваться HTML?».

На первый взгляд кажется, что разница невелика — пользователь в итоге видит одну и ту же страницу. Но на деле выбор между Client-Side Rendering (CSR), Server-Side Rendering (SSR), Static Site Generation (SSG) и Incremental Static Regeneration (ISR) радикально влияет на SEO, скорость первой загрузки (LCP), нагрузку на сервер и общую стоимость поддержки инфраструктуры.

В этой статье мы разберем каждый подход «под капотом», выясним их слабые места и определим, какой метод выбрать для конкретных бизнес-задач.

1. CSR (Client-Side Rendering): Всё делает браузер

Client-Side Rendering — это классический подход для Single Page Applications (SPA). При запросе страницы сервер отправляет браузеру минимальный HTML-файл (обычно с одним пустым тегом <div id="app"></div>) и огромный бандл JavaScript. Весь процесс построения интерфейса происходит уже на устройстве пользователя.

Как это работает:

  1. Браузер запрашивает страницу.
  2. Сервер отдает «пустой» HTML и ссылку на JS-скрипты.
  3. Браузер скачивает JS, исполняет его.
  4. JS делает API-запросы к бэкенду за данными.
  5. Данные приходят, и JS отрисовывает контент в DOM.

Плюсы:

    • Отсутствие перезагрузок: После первой загрузки переходы между страницами происходят мгновенно.
    • Снижение нагрузки на сервер: Сервер просто отдает статические файлы, вся вычислительная работа ложится на клиент.
    • Идеально для интерфейсов: Личные кабинеты, CRM-системы, админ-панели.

Минусы:

    • Плохое SEO: Хотя GoogleBot научился исполнять JS, многие другие поисковики и соцсети (при генерации превью ссылок) видят пустую страницу.
    • Медленный First Contentful Paint (FCP): Пользователь видит белый экран, пока скачивается и исполняется весь JS-бандл.

2. SSR (Server-Side Rendering): Классика в новой обертке

SSR возвращает нас к истокам веба, но с комфортом современных фреймворков. Здесь HTML генерируется на сервере при каждом отдельном запросе пользователя.

Как это работает:

  1. Пользователь запрашивает страницу.
  2. Сервер получает запрос, делает запросы к базе данных или API.
  3. Сервер «собирает» полноценный HTML-документ с данными.
  4. Браузер получает готовый HTML и сразу отображает его.
  5. Затем происходит «гидратация» (hydration) — JS подключается к готовому HTML, делая страницу интерактивной.

Плюсы:

    • Отличное SEO: Поисковики получают полностью сформированный контент сразу.
    • Быстрый первый рендер: Пользователь видит контент почти мгновенно, даже на слабых устройствах.
    • Актуальность данных: Контент всегда свежий, так как страница генерируется в момент запроса.

Минусы:

    • Нагрузка на сервер: Каждый визит требует ресурсов CPU и RAM сервера для рендеринга.
    • Time to First Byte (TTFB): Серверу нужно время, чтобы собрать страницу, поэтому ответ может прийти с небольшой задержкой.

3. SSG (Static Site Generation): Максимальная скорость

SSG — это подход, при котором весь сайт превращается в набор статичных HTML-файлов еще на этапе сборки (build time).

Как это работает:

    1. В момент запуска команды npm run build фреймворк проходит по всем маршрутам сайта.
    1. Для каждой страницы делает запросы к API и генерирует статический HTML-файл.
    1. Эти файлы выкладываются на CDN (Content Delivery Network).
    1. Пользователь получает файл из ближайшего к нему дата-центра.

Плюсы:

    • Невероятная скорость: Это самый быстрый способ доставки контента.
    • Безопасность и отказоустойчивость: Нет активного сервера приложений — нечего взламывать или «уронить» при наплыве трафика.
    • Дешевый хостинг: Статику можно хостить бесплатно или очень дешево (Vercel, Netlify, GitHub Pages).

Минусы:

    • Проблема обновления: Чтобы изменить одну запятую в статье, нужно пересобирать весь проект и заново деплоить его.
    • Время сборки: Если у вас 100 000 товаров в интернет-магазине, сборка проекта может затянуться на часы.

4. ISR (Incremental Static Regeneration): Золотая середина

ISR — это современная эволюция SSG, которая решает проблему долгой пересборки. Она позволяет обновлять статические страницы в фоновом режиме без полного редеплоя сайта.

Как это работает:

  1. Вы задаете время «свежести» для страницы (например, 60 секунд).
  2. Первый пользователь получает статическую версию из кэша.
  3. Если через 60 секунд приходит другой пользователь, он всё еще видит старую версию, но сервер в фоновом режиме запускает пересборку этой конкретной страницы.
  4. Следующий пользователь уже получает обновленный HTML.

Плюсы:

    • Масштабируемость: Можно иметь миллионы страниц, не дожидаясь окончания билда.
    • Скорость SSG + Актуальность SSR: Пользователи получают статику, но данные обновляются автоматически.

Минусы:

    • Сложность кэширования: Нужно аккуратно настраивать заголовки кэша, чтобы не запутать пользователя и поисковики.
    • Не подходит для персональных данных: ISR не может генерировать страницу «Мой профиль», так как контент индивидуален.

Сравнительная таблица для быстрого выбора

Критерий CSR SSR SSG ISR
SEO $\text{Low}$ $\text{High}$ $\text{High}$ $\text{High}$
Скорость первой загрузки $\text{Slow}$ $\text{Medium}$ $\text{Fastest}$ $\text{Fastest}$
Нагрузка на сервер $\text{Low}$ $\text{High}$ $\text{Minimal}$ $\text{Low}$
Актуальность данных $\text{Real-time}$ $\text{Real-time}$ $\text{At build time}$ $\text{Near real-time}$
Сложность реализации $\text{Simple}$ $\text{Medium}$ $\text{Simple}$ $\text{Medium}$

Какой подход выбрать для вашего проекта?

Чтобы не ошибиться с выбором, задайте себе три вопроса: Нужно ли мне SEO? Насколько часто меняются данные? Сколько у меня страниц?

Сценарий 1: Сложный веб-сервис (SaaS, Dashboard, CRM)

Если ваш продукт — это закрытая система с авторизацией, где данные меняются каждую секунду и SEO не имеет значения, ваш выбор — CSR.

    • Почему: Пользователю важнее плавность интерфейса, а серверу — не захлебнуться от тысяч мелких запросов на рендер HTML.

Сценарий 2: Новостной портал или крупный блог

Здесь критически важно SEO и высокая скорость загрузки, но контент обновляется несколько раз в час. Идеальный вариант — ISR.

    • Почему: Вы получаете скорость статики, но вам не нужно пересобирать весь сайт из 5000 статей ради исправления опечатки в одной из них.

Сценарий 3: Интернет-магазин (Каталог + Карточки товаров)

Для главной страницы и категорий лучше использовать ISR или SSG. Для страниц с динамическими ценами или остатками на складе в реальном времени — SSR.

    • Почему: Карточка товара должна индексироваться поисковиками (SSG/ISR), но актуальная цена должна быть точной на момент покупки (SSR).

Сценарий 4: Лендинг, сайт-визитка или документация

Если контент меняется раз в месяц, однозначно выбирайте SSG.

    • Почему: Это максимально дешево, безопасно и быстро.

Заключение

В современной разработке нет «единственно правильного» метода. Лучшие проекты используют гибридный подход. Например, Next.js позволяет использовать разные стратегии для разных маршрутов одного приложения: главная страница может быть SSG, каталог — ISR, личный кабинет — CSR, а страница оформления заказа — SSR.

Главное правило: не усложняйте там, где это не нужно. Если вам достаточно простого React-приложения, не внедряйте SSR только потому, что это «модно». Но если ваша цель — топ выдачи Google и мгновенный отклик для пользователя, инвестиции в ISR и SSR окупятся стократно.