SSR-стратегия для продуктовых интерфейсов

Начать со страницы, а не с аббревиатуры

Представим приложение с публичным каталогом, страницами объектов и личным кабинетом. У него один frontend, но разные требования к первому экрану. Посетителю каталога нужно увидеть предложения, поисковой системе — получить содержимое страницы, а пользователю кабинета — продолжить работу со своими данными.

Поэтому вопрос «нужен ли приложению SSR?» слишком широкий. Полезнее спросить: какое содержимое должно прийти в первом HTML, насколько оно персональное и как быстро устаревает? Ответы помогают выбрать стратегию отдельно для каждого типа страниц. Пример здесь условный: это разбор решения, а не отчёт о конкретном проекте.

Три способа получить первый экран

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

SSR формирует HTML на сервере во время запроса. Он подходит, когда первому экрану нужны актуальные или зависящие от запроса данные. Цена решения — серверная работа и зависимость времени ответа от источников данных. Сам по себе SSR не гарантирует быстрый интерфейс.

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

Зафиксировать решение на уровне маршрутов

Для условного приложения можно начать с такой карты: статьи — статическая генерация; публичная карточка с актуальными данными — серверный рендеринг; насыщенный взаимодействиями кабинет — клиентский рендеринг, если это устраивает по скорости первого открытия. Это гипотеза для проверки, а не правило для любого каталога.

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

import { RenderMode, type ServerRoute } from '@angular/ssr';

export const serverRoutes: ServerRoute[] = [
  { path: 'articles', renderMode: RenderMode.Prerender },
  { path: 'catalog/:id', renderMode: RenderMode.Server },
  { path: 'account/**', renderMode: RenderMode.Client },
  { path: '**', renderMode: RenderMode.Server },
];

Где обычно появляются сложности

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

Отдельная задача — кеш. Публичное описание объекта и личные данные пользователя нельзя бездумно хранить по одному правилу. Для персональных ответов нужно учитывать авторизацию и правила кеширования; для публичных — допустимый срок устаревания и способ обновления.

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

Проверить решение на реальном сценарии

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

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

• Основное содержимое доступно при прямом открытии ссылки.
• Персональные данные не попадают в общий кеш.
• Первое взаимодействие не блокируется тяжёлой инициализацией.
• Ошибки источника данных имеют понятное состояние интерфейса.