«Нам нужен SSR, а лучше ISR, как в Next.js» — фраза, которую всё чаще произносят на старте проекта магазина, не всегда понимая, что за ней стоит и зачем это платформе на 1С-Битрикс. Тема рендеринга окружена модными аббревиатурами, но за ними — простой и важный вопрос: как и когда собирается HTML-страница, которую видят пользователь и поисковик. От ответа зависят и скорость, и SEO, и нагрузка на сервер.
В этой статье разберём SSR, SSG и ISR без хайпа: что каждый режим значит, чем отличается, какой подходит магазину и как всё это соотносится с композитным сайтом и кэшем 1С-Битрикс. И честно ответим, когда классического Битрикс достаточно, а когда стоит думать о headless-фронтенде. Архитектурные решения такого уровня мы закладываем в рамках услуги автоматизации на 1С.
Коротко
- SSR — сборка страницы на сервере при запросе, SSG — заранее в статику, ISR — статика с фоновым обновлением.
- Магазину нужен готовый HTML для SEO: чистый клиентский рендеринг (CSR) для каталога рискован.
- Композитный сайт 1С-Битрикс по идее близок к ISR — кэширует HTML и обновляет по событиям.
- Headless-фронтенд оправдан не всегда; часто классический Битрикс с грамотным кэшем закрывает задачу.
Зачем магазину вообще думать о рендеринге
Рендеринг — это то, как и когда собирается HTML, который получает браузер. Для интернет-магазина это не абстракция, а вопрос трёх практичных вещей: увидит ли поисковик контент (SEO), как быстро страница появится у пользователя (скорость) и какую нагрузку это создаст на сервер (стоимость и устойчивость).
Каталог и карточки — контентные страницы, которые должны индексироваться и открываться мгновенно, но при этом показывать актуальные цену и наличие. Это конфликтующие требования: свежесть данных тянет к генерации при каждом запросе, а скорость и нагрузка — к статике. Разные режимы рендеринга — это разные способы разрешить этот конфликт.
SSR: рендеринг на сервере при запросе
SSR (server-side rendering) — классическая модель: на каждый запрос сервер собирает готовую HTML-страницу и отдаёт её браузеру. Именно так по умолчанию работает обычная страница на PHP в 1С-Битрикс — компонент выбирает данные, шаблон формирует разметку, пользователь получает готовый контент.
- Плюс: всегда свежие данные. Цена и наличие актуальны, потому что берутся при каждом запросе.
- Плюс: хорошо для SEO. Поисковик получает готовый HTML сразу.
- Минус: нагрузка на сервер. Каждый запрос — это работа базы и PHP, на пике трафика больно.
- Минус: медленнее статики. Сборка занимает время — растёт время до первого байта.
SSR без кэша — самый ресурсоёмкий режим. Поэтому в реальности его почти всегда дополняют кэшированием, и вопрос смещается к тому, насколько агрессивно закэширован результат.
SSG: статика, собранная заранее
SSG (static site generation) — противоположный подход: страницы генерируются заранее, при сборке, и сохраняются как статические HTML-файлы. Пользователь получает готовый файл мгновенно, без работы сервера на лету.
Для магазина у SSG двойственная природа. С одной стороны, это максимальная скорость и минимальная нагрузка. С другой — данные «замораживаются» на момент сборки: чтобы обновить цену или наличие, нужна пересборка. Для огромного каталога пересборка миллионов страниц долгая и непрактичная. Поэтому чистый SSG хорош для редко меняющегося контента (статьи, лендинги), но проблематичен для живого каталога с ценами.
ISR: статика с фоновым обновлением
ISR (incremental static regeneration) — гибрид, снимающий главный недостаток SSG. Страницы отдаются как статика, но фоново перегенерируются: по времени жизни, по расписанию или по событию изменения данных. Первый посетитель получает закэшированную версию, а обновление происходит в фоне, не пересобирая весь сайт.
Для интернет-магазина ISR-подход — обычно оптимальный компромисс: скорость статики без замороженных данных и без пересборки всего каталога. Разница с SSG в том, что регенерация инкрементальная — обновляется только то, что изменилось.
CSR и почему он опасен для каталога
Отдельно стоит упомянуть CSR (client-side rendering) — когда сервер отдаёт почти пустую страницу, а весь контент дорисовывает JavaScript в браузере. Это удобно для интерактивных приложений, но опасно для каталога магазина.
Проблема в SEO: поисковик может получить пустую страницу и не дождаться, пока JavaScript подгрузит товары и текст. Контент рискует не проиндексироваться, а значит — не появиться в выдаче. Плюс первый экран у пользователя появляется позже. Поэтому для контентных страниц магазина (каталог, карточки, разделы) чистый CSR — рискованный выбор; им уместно рендерить только динамические виджеты поверх серверного HTML.
Сравнение режимов для магазина
| Режим | Когда собирается HTML | Свежесть данных | Нагрузка | SEO |
|---|---|---|---|---|
| SSR | При каждом запросе | Максимальная | Высокая | Отлично |
| SSG | Заранее при сборке | На момент сборки | Минимальная | Отлично |
| ISR | Статика + фоновая регенерация | Высокая | Низкая | Отлично |
| CSR | В браузере (JS) | Высокая | Низкая на сервер | Рискованно |
Для типичного магазина побеждает ISR-подход: готовый HTML для SEO, скорость статики, низкая нагрузка и достаточная свежесть за счёт регенерации по событиям. SSR остаётся для по-настоящему персональных страниц, CSR — для динамических виджетов поверх статики.
Как это ложится на 1С-Битрикс
Хотя термины SSR/SSG/ISR родом из мира JavaScript-фреймворков, идеи прямо переносятся на 1С-Битрикс. Классическая страница на PHP — это по сути SSR: сервер собирает HTML при запросе. Кэш компонентов и меню приближает поведение к статике: результат генерации сохраняется и переиспользуется. А композитный сайт — это уже гибрид, близкий к ISR.
Поэтому «выбор рендеринга» на Битрикс — это в первую очередь настройка стратегии кэширования: что генерировать на лету, что кэшировать, когда сбрасывать кэш. Понимание режимов помогает выстроить это осознанно, а не оставлять на самотёк. Смежные архитектурные темы — D7 ORM для эффективных выборок и разработка модулей для кастомной логики.
Композитный сайт как ISR из коробки
Композитный сайт — штатный механизм 1С-Битрикс, который по идее ближе всего к ISR. Он берёт результат серверной генерации, кэширует статический HTML и отдаёт его почти мгновенно, а изменяемые части подгружает отдельно. Кэш обновляется по событиям изменения данных.
- Первое обращение. Страница генерируется сервером и кэшируется как статический HTML.
- Последующие обращения. Отдаётся готовый кэш — мгновенно, без работы базы.
- Динамические зоны. Корзина, авторизация, цена клиента догружаются отдельным запросом.
- Регенерация. Кэш сбрасывается по событию (изменился товар) или по времени жизни.
Это и есть инкрементальная статика: скорость отдачи как у SSG, актуальность как у SSR, без пересборки всего каталога. Для большинства магазинов грамотно настроенный композит закрывает задачу без внешних фреймворков.
Динамические данные: цена, наличие, корзина
Главная сложность любого статического подхода в магазине — данные, которые меняются чаще, чем регенерируется страница: цена (особенно по группам клиентов в B2B), наличие на складе, содержимое корзины, авторизация. Их нельзя «запекать» в статику надолго.
Решение общее для всех режимов: вынести динамику из кэшируемой части и подгружать отдельно — быстрым серверным ответом или запросом из браузера. В композитном сайте это делается разметкой динамических зон. Так основной контент (описание, характеристики, изображения) отдаётся мгновенно из кэша, а цена и остатки всегда свежие, потому что запрашиваются отдельно. Наличие и цены при этом приходят из учётной системы — качество обмена мы закрываем услугой автоматизации продаж и склада на 1С, а технику интеграций разбирали в статье про REST, вебхуки и безопасность.
Когда нужен headless-фронтенд
Headless-архитектура — это когда Битрикс остаётся бэкендом и отдаёт данные через API, а фронтенд делают отдельным приложением (например, на React/Next.js) с собственным SSR/SSG/ISR. Это мощно, но не всегда оправдано.
- Оправдано: сложный интерактив, общий бэкенд для сайта и мобильного приложения, высокие требования к фронтенду, отдельная фронтенд-команда.
- Избыточно: типовой магазин, где композитный сайт и кэш Битрикс уже дают нужную скорость и SEO.
Headless дороже в разработке и поддержке, требует выстроенного API и дисциплины деплоя — эти темы мы разбирали в статьях про CI/CD и деплой и разработку модуля для Маркетплейса. Прежде чем уходить в headless, стоит убедиться, что классический Битрикс действительно не тянет задачу — часто оказывается, что тянет.
Частые ошибки выбора
- Гонятся за модой. Берут headless и ISR «потому что современно», хотя композита хватило бы.
- CSR для каталога. Отдают пустую страницу, товары рисует JS — контент не индексируется.
- SSR без кэша. Каждая страница собирается заново, сервер падает под нагрузкой.
- Цена в статике. Динамические данные запекают в кэш, клиент видит устаревшую цену.
- SSG для живого каталога. Пытаются пересобирать миллионы страниц при каждом изменении.
- Кэш без стратегии сброса. Не настроено, когда обновлять — либо устаревает, либо не кэшируется.
- Недооценка стоимости headless. Уходят в отдельный фронтенд без ресурсов на его поддержку.
Чек-лист выбора рендеринга
- Контент отдаётся готовым HTML. Каталог и карточки не зависят от клиентского JS для индексации.
- Композит включён. Основные страницы кэшируются и отдаются мгновенно.
- Динамика вынесена. Цена, наличие, корзина, авторизация — отдельно от статического кэша.
- Стратегия сброса кэша описана. Понятно, что и по какому событию регенерируется.
- Свежесть данных достаточна. Цена и остатки актуальны, обмен с 1С стабилен.
- Нагрузка проверена. Поведение под пиком трафика протестировано.
- Headless обоснован. Отдельный фронтенд берут только при реальной необходимости и ресурсах.
Вывод
SSR, SSG и ISR — это не магия и не обязательно про JavaScript-фреймворки, а три способа ответить на один вопрос: когда собирается HTML. Для интернет-магазина почти всегда выигрывает ISR-подход: готовый контент для SEO, скорость статики, низкая нагрузка и достаточная свежесть за счёт регенерации. И именно эту идею реализует композитный сайт 1С-Битрикс из коробки.
Поэтому на Битрикс «выбор рендеринга» — это грамотная настройка кэша: что генерировать на лету, что кэшировать, когда сбрасывать, и как вынести динамику вроде цены и наличия. Headless-фронтенд — мощный инструмент, но не самоцель: прежде чем усложнять, убедитесь, что классический Битрикс с продуманным кэшем не решает задачу. Чаще всего — решает.
