SSR, SSG, пререндеринг и ISR: полное сравнение для React-сайта

Для React-сайта нет универсального способа рендеринга: SSR формирует HTML на сервере при запросе, SSG создаёт страницы заранее, пререндеринг сохраняет готовый HTML для выбранных маршрутов, а ISR обновляет статические страницы постепенно, без полной пересборки проекта. Выбор зависит от того, как часто меняются данные, нужна ли персонализация, сколько страниц у проекта, какие требования предъявляются к SEO, скорости и инфраструктуре.

Содержание

• Что означает рендеринг страницы
• SSR: HTML формируется при запросе
• SSG: страницы создаются во время сборки
• Пререндеринг: готовый HTML для маршрутов
• ISR: обновление статических страниц
• Сравнение стратегий
• Как выбрать подход для сайта
• Ошибки и ограничения
• Практические сценарии
• FAQ
• Чек-лист выбора

Что означает рендеринг страницы

Рендеринг — это формирование HTML, который браузер получает и отображает. В React-компонентах описывается интерфейс, но пользователь и поисковый робот работают не с исходным JSX, а с результатом его преобразования в HTML и последующего выполнения JavaScript.

Упрощённо у страницы есть два слоя:

• HTML, который можно получить от сервера до запуска клиентского JavaScript;
• интерактивность, которую React подключает в браузере.

Для публичных страниц важно различать эти слои. Текст статьи, заголовок, ссылки, навигация и основные данные должны быть доступны в HTML. Кнопки, меню, фильтры, маски форм и калькуляторы могут подключаться после загрузки.

Если сервер отдаёт только оболочку приложения с пустым контейнером root, пользователю приходится ждать JavaScript. Поисковая система также может перейти к отдельному этапу рендеринга. Google описывает обработку JavaScript-страниц как последовательность обхода, рендеринга и индексации. Поэтому готовый HTML уменьшает зависимость страницы от выполнения клиентского кода.

Стратегия рендеринга влияет сразу на несколько характеристик:

• доступность основного содержания для роботов;
• время получения первого HTML;
• нагрузку на сервер;
• скорость сборки и публикации;
• сложность кеширования;
• возможность обновлять данные без полной пересборки;
• требования к хостингу и деплою.

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

SSR: HTML формируется при запросе

SSR, или Server-Side Rendering, означает серверный рендеринг. Когда пользователь или робот запрашивает URL, сервер получает необходимые данные, формирует React-дерево и отправляет готовый HTML в ответе.

Типичная последовательность выглядит так:

1. Браузер запрашивает URL.
2. Сервер определяет маршрут.
3. Сервер получает данные страницы.
4. React формирует HTML.
5. Сервер отправляет HTML браузеру.
6. Браузер показывает содержание.
7. Клиентский React выполняет гидратацию и подключает интерактивность.

Для серверного рендеринга React предоставляет API renderToString и renderToPipeableStream. Первый возвращает HTML-строку, второй позволяет передавать результат потоково через Node.js stream. После получения HTML браузер может вызвать hydrateRoot, чтобы подключить обработчики событий и сделать серверную разметку интерактивной.

Простейшая концепция серверного рендера:

import { renderToString } from "react-dom/server";
import App from "./App";

const html = renderToString(<App />);

На клиенте серверную разметку обычно гидратируют:

import { hydrateRoot } from "react-dom/client";
import App from "./App";

hydrateRoot(document.getElementById("root")!, <App />);

Когда нужен SSR

SSR подходит для страниц, данные которых должны формироваться непосредственно перед ответом:

• каталог с часто меняющимися остатками;
• страница поиска с параметрами запроса;
• персонализированное содержимое;
• данные, зависящие от авторизации;
• динамические цены или доступность;
• страницы, которые нельзя заранее создать для всех вариантов URL.

Серверный рендеринг также полезен, когда проект содержит много динамических маршрутов и не может генерировать их все на этапе сборки.

Преимущества SSR

• HTML создаётся для конкретного запроса.
• Сервер может использовать актуальные данные.
• Не требуется заранее генерировать все варианты страницы.
• Основной текст и структура могут попасть в первый ответ.
• Один и тот же маршрут может показывать разные данные в зависимости от запроса.

Ограничения SSR

• Сервер выполняет рендеринг при каждом запросе, если результат не кешируется.
• Увеличивается нагрузка на CPU и память.
• Ошибка API может повлиять на HTML страницы.
• Требуется серверная среда, способная выполнять приложение.
• Нужно контролировать время ответа и кеширование.
• Серверный HTML и клиентский React должны совпадать при гидратации.

SSR не означает автоматически быструю страницу. Если сервер долго получает данные, итоговый HTML задерживается. На результат влияют время выполнения React, запросы к базе или API, сетевые задержки и настройки кеша.

SSG: страницы создаются во время сборки

SSG, или Static Site Generation, означает статическую генерацию. HTML создаётся заранее, до того как пользователь откроет страницу. Сгенерированные файлы затем размещаются на веб-сервере, CDN или статическом хостинге.

Последовательность SSG:

1. Система получает список маршрутов.
2. Для каждого маршрута загружаются данные.
3. React формирует HTML.
4. HTML сохраняется в файл.
5. Статические файлы публикуются.
6. Сервер отдаёт готовый результат без рендера React на каждом запросе.

Пример результата сборки:

dist/
  index.html
  about/
    index.html
  blog/
    react-seo/
      index.html
  services/
    website-development/
      index.html

Для блога это означает, что статья превращается в готовый HTML ещё до публикации сборки. При открытии URL сервер отдаёт уже созданный файл.

Когда нужен SSG

SSG подходит для контента, который не меняется при каждом запросе:

• статьи блога;
• страницы услуг;
• документация;
• страницы «О компании»;
• кейсы;
• географические посадочные страницы;
• справочные материалы;
• лендинги.

Для сайта Like Sites статические страницы блога, услуги и материалы о разработке можно рассматривать как основные кандидаты на SSG или статический пререндеринг.

Преимущества SSG

• HTML готов до запроса пользователя.
• Страницы можно отдавать через CDN.
• Серверу не нужно выполнять React на каждом просмотре.
• Кеширование проще, чем при динамическом рендеринге.
• Нет зависимости от доступности API во время каждого просмотра.
• Результат удобно проверять через curl и просмотр исходного кода.
• Статические файлы можно размещать на простом хостинге.

Ограничения SSG

• После изменения данных обычно требуется новая сборка.
• Большое количество страниц увеличивает длительность сборки.
• Неудобно заранее генерировать бесконечное число параметров и фильтров.
• Данные могут устаревать до следующего деплоя.
• Список маршрутов должен формироваться корректно.
• Неизвестные URL должны обрабатываться отдельно, чтобы не превращать их в страницы с кодом 200.

SSG не означает, что сайт полностью лишён JavaScript. Статический HTML может быть основой, а React после загрузки подключает интерактивные компоненты.

Пререндеринг: готовый HTML для маршрутов

Пререндеринг — это предварительное формирование HTML для определённых маршрутов React-приложения. В практическом смысле статический пререндеринг является способом получить SSG-результат для клиентского приложения, которое иначе отдавало бы app shell.

App shell — это минимальная оболочка приложения: HTML-документ, контейнер для React и ссылки на JavaScript. Если в оболочке нет текста страницы, пользователь и робот должны дождаться выполнения приложения. Пререндеринг заменяет пустую оболочку готовым HTML конкретного маршрута.

Схема пререндеринга:

1. В проекте задаётся список публичных URL.
2. Для каждого URL запускается приложение.
3. Получается содержимое маршрута.
4. DOM сохраняется в отдельный HTML-файл.
5. При запросе URL сервер отдаёт соответствующий файл.
6. React при необходимости гидратирует HTML в браузере.

Например, для блога список может содержать:

/
/blog/
/blog/javascript-seo-react/
/blog/ssg-vs-spa-dlya-biznes-sayta/
/services/web-development/

Каждый маршрут должен получить собственный результат. Нельзя сгенерировать один HTML-файл и выдавать его для всех статей, если страницы должны иметь разные заголовки, тексты, canonical и структурированные данные.

Пререндеринг и динамический рендеринг

Статический пререндеринг не следует путать с динамическим рендерингом для роботов. При динамическом рендеринге сервер определяет User-Agent и может отдавать роботам отдельную HTML-версию, а пользователям — клиентскую версию.

Google описывает dynamic rendering как обходной вариант для сайтов, где JavaScript-контент недоступен поисковым системам, и указывает, что такой подход добавляет сложности. Для новой архитектуры предпочтительнее, чтобы пользователи и роботы получали одинаковое по смыслу содержание.

Когда нужен пререндеринг

Пререндеринг подходит, если:

• проект уже построен как SPA;
• нужно быстро сделать публичные маршруты доступными в HTML;
• страницы меняются не при каждом запросе;
• список URL можно получить во время сборки;
• отдельный SSR-сервер пока не нужен;
• важно сохранить существующую React-архитектуру.

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

ISR: обновление статических страниц

ISR, или Incremental Static Regeneration, — инкрементальная регенерация статических страниц. Страница создаётся как статическая, но может обновляться отдельно от полной сборки всего проекта.

В реализации Next.js ISR позволяет создавать или обновлять статические страницы после сборки. Страница может обслуживаться из кеша, а после истечения заданного времени инициируется её фоновая регенерация. Успешно созданная новая версия заменяет старую. Если регенерация завершается ошибкой, прежняя версия может продолжить обслуживаться.

Упрощённый сценарий:

1. Страница создаётся во время сборки или первого запроса.
2. Готовая версия помещается в кеш.
3. Пользователи получают кешированный HTML.
4. После заданного интервала страница становится кандидатом на обновление.
5. Следующий запрос может получить старую версию, пока новая создаётся в фоне.
6. После успешной генерации кеш заменяется.

В некоторых системах страницы можно обновлять по событию: например, после публикации записи CMS отправить запрос на регенерацию конкретного URL. В других системах применяется временной интервал.

Когда нужен ISR

ISR полезен для проектов, где:

• страниц много;
• данные обновляются периодически;
• полная сборка занимает слишком много времени;
• не нужна генерация при каждом запросе;
• допустима небольшая задержка перед появлением обновления;
• часть страниц должна обновляться отдельно.

Например, каталог из большого количества страниц может не требовать полного SSR, если изменения происходят раз в час или после обновления карточки. Статическая выдача снижает нагрузку, а инкрементальное обновление позволяет не собирать заново весь проект.

Ограничения ISR

ISR не является стандартной возможностью самого React. Это архитектурный механизм конкретного фреймворка или платформы. Поэтому нужно заранее проверить, поддерживает ли выбранный стек:

• генерацию страниц после сборки;
• кеширование HTML;
• фоновую регенерацию;
• обновление по событию;
• обработку ошибок регенерации;
• очистку или обновление CDN-кеша.

Также необходимо определить допустимую задержку обновления. Если пользователю всегда нужны данные в реальном времени, ISR может не подойти. Для таких страниц нужен SSR или клиентское получение актуальных данных.

Сравнение стратегий

Таблица показывает общую модель. Реальные возможности зависят от фреймворка, адаптера, хостинга, CDN и способа получения данных.

Как выбрать подход

Для статьи блога

Статья обычно имеет постоянный URL и меняется только при редактировании. Для неё подходит SSG или пререндеринг. После изменения Markdown-файла или записи CMS запускается сборка, а сервер получает новый HTML.

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

Для страницы услуги

Страница услуги обычно содержит текст, заголовки, блоки доверия, FAQ, форму и призыв к действию. Основное содержание можно генерировать статически. Форма и аналитика могут работать на клиенте.

Если цена, доступность или набор предложений меняются часто, динамическую часть можно получать отдельно, не переводя весь документ на SSR.

Для географической страницы

Если геостраницы заранее известны и каждая имеет уникальные данные, SSG или пререндеринг позволяют создать отдельный HTML для каждого URL. Нельзя ограничиваться заменой названия города в одинаковом шаблоне: страница должна быть полезной для конкретного региона и не создавать массовые дубли.

Для каталога

Если каталог содержит ограниченное количество стабильных карточек, подходит SSG. Если карточек много и они обновляются периодически, можно рассмотреть ISR. Если результат зависит от фильтров, пользователя, остатков или запроса, применяют SSR или комбинацию серверного HTML и клиентского обновления.

Для личного кабинета

Личный кабинет не является обычной SEO-посадочной страницей. Данные зависят от пользователя и авторизации, поэтому CSR или SSR с проверкой сессии могут быть уместнее SSG. Закрытые разделы также должны иметь корректные ограничения доступа и HTTP-статусы.

Архитектура смешанного сайта

На одном проекте не обязательно использовать одну стратегию для всех маршрутов. Практичный вариант — разделить сайт по назначению:

• публичная главная страница — SSG или SSR;
• блог — SSG, пререндеринг или ISR;
• страницы услуг — SSG;
• географические страницы — SSG или пререндеринг;
• каталог с часто меняющимися данными — ISR или SSR;
• личный кабинет — CSR или SSR с авторизацией;
• административная часть — CSR.

Такой подход позволяет не применять тяжёлый SSR там, где достаточно готового файла, и не пытаться статически генерировать персональные данные.

Главное условие — для каждого публичного маршрута должен существовать корректный HTML-результат. В нём должны быть основной контент, H1, ссылки, title, description и canonical. Клиентский React может улучшать интерфейс, но не должен быть единственным источником важных данных.

Ошибки и ограничения

Выбор технологии по популярности

SSR не становится правильным только потому, что он считается современным. Если сайт состоит из статей и страниц услуг, постоянный серверный рендеринг может добавить сложность без необходимости.

Полная пересборка при каждом изменении

Для небольшого блога полная пересборка не обязательно является проблемой. Для большого каталога она может стать узким местом. В таком случае рассматривают ISR, on-demand regeneration или разделение проекта на части.

Пустой app shell

SPA может быстро загружать JavaScript, но при этом отдавать пустой HTML. Для публичных SEO-страниц нужно проверить, присутствует ли содержание в исходном ответе.

Ошибка маршрутизации

Статический сервер должен знать, какой файл вернуть для URL. Если любой адрес получает главную страницу, несуществующие маршруты могут возвращаться с кодом 200. Для ошибки нужен корректный 404 или 410.

Несовпадение при гидратации

Если сервер и браузер формируют разный результат, появляются hydration mismatch. Нельзя без проверки использовать в серверном дереве случайные значения, текущее время, доступ к window или данные, которые есть только в браузере.

Неправильная свежесть данных

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

Динамический рендеринг только для роботов

Отдельные версии для робота и пользователя усложняют поддержку и контроль соответствия. Если используется такой временный механизм, его нужно регулярно пересматривать и проверять, что версии не расходятся по смыслу.

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

После реализации проверьте каждый тип маршрута.

Проверка HTML

Выполните запрос к опубликованному URL:

curl -L https://example.ru/blog/article/

Убедитесь, что в ответе присутствуют H1, основной текст, внутренние ссылки, title и canonical. Если виден только контейнер root и ссылки на JavaScript, страница не отдаёт готовое содержание на сервере.

Проверка статуса

Проверьте существующую страницу:

curl -I https://example.ru/blog/article/

Затем проверьте неизвестный URL:

curl -I https://example.ru/blog/not-found/

Существующий маршрут обычно должен возвращать 200, а неизвестный — 404 или другой корректный статус по правилам проекта.

Проверка после JavaScript

Сравните исходный HTML и DOM после выполнения JavaScript в браузере. Убедитесь, что React не удаляет текст, не меняет canonical на ошибочный URL и не заменяет страницу экраном загрузки.

Проверка обновления

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

Проверка внутренних ссылок

Важные страницы должны быть доступны через обычные ссылки с href. Одной навигации через обработчик onClick недостаточно для надёжного обнаружения маршрутов.

Чек-лист выбора

• Определено, как часто меняются данные.
• Понятно, нужна ли персонализация.
• Составлен список публичных маршрутов.
• Решено, должен ли контент присутствовать в первом HTML.
• Выбран SSR, SSG, пререндеринг или ISR для каждой группы страниц.
• Проверены требования хостинга и сервера.
• Описан процесс сборки и деплоя.
• Настроено кеширование HTML и статических ресурсов.
• Проверены HTTP-коды существующих и несуществующих URL.
• Проверена гидратация React.
• В HTML присутствуют H1, текст, ссылки и метаданные.
• Важные ссылки используют обычный href.
• Для ISR определён срок или событие обновления.
• Предусмотрено поведение при ошибке получения данных.
• Проверены исходный HTML и DOM после JavaScript.
• Выполнена проверка через инструменты поисковых систем.

Итог

SSR формирует HTML на сервере во время запроса и подходит для динамических данных. SSG создаёт страницы заранее и удобен для блога, документации, услуг и стабильных посадочных страниц. Пререндеринг позволяет подготовить HTML для выбранных маршрутов React-приложения. ISR сохраняет преимущества статической выдачи и добавляет возможность обновлять отдельные страницы без полной пересборки всего сайта.

Для SEO-ориентированного сайта важно не название технологии, а результат: поисковик и пользователь должны получать корректный документ с доступным содержанием, уникальными метаданными, рабочими ссылками и правильным HTTP-статусом. Для Like Sites разумно использовать смешанную архитектуру: публичный стабильный контент генерировать заранее, динамические данные обрабатывать серверно или инкрементально, а интерактивность оставлять клиентскому React.

Официальные материалы

• Google Search Central: основы JavaScript SEO
• Google Search Central: динамический рендеринг
• Google Search Central: исправление проблем JavaScript
• React: renderToString
• React: renderToPipeableStream
• React: hydrateRoot
• Next.js: Incremental Static Regeneration