Рендеринг в Next.js: как мы выбираем между SSR, SSG, ISR и Streaming

В App Router Next.js стратегии рендеринга — это не «галочки в конфиге», а архитектурные решения с влиянием на стоимость, метрики и операционку. Мы выбираем между SSR (серверный рендер на каждый запрос), SSG (статическая генерация),ISR (инкрементальная регенерация) и Streaming (потоковая отдача UI) на уровне маршрута и даже отдельного блока. В статье — инженерный подход к принятию решения, модели данных, кэш и теги, гибридные страницы и анти-паттерны, с которыми сталкивалась наша команда.

0) Картина мира: чем стратегии отличаются на практике

• SSR: свежие данные по запросу, выше нагрузка, зависимость от бэкендов. Хорош для персонализации и страниц «сейчас и точно».
• SSG: мгновенная раздача с края (CDN), дёшево по CPU. Подходит для стабильного контента и SEO-витрин.
• ISR: SSG + фоновая регенерация. Комфортная середина для новостей/каталогов и CMS-контента.
• Streaming: отдаём «скелет» страницы сразу, догружаем тяжёлые секции позже. Снижает TTFB→FCP/INP, убирает «белый экран».

1) Как мы принимаем решение по маршруту

Мы ранжируем требования: свежесть данных, персонализация, SLA бэкендов, бюджет кэша, география. Затем строим матрицу: «страница × стратегия», где каждая клетка имеет стоимость CPU, сложность кэширования, влияние на Web Vitals. Итог — гибрид: например, «категория каталога» на ISR, «карточка товара» — Streaming+ISR, «аккаунт» — SSR/Streaming.

Гайд-вопросы

• Насколько критична свежесть? (минуты/часы/дни)
• Нужна ли персонализация/авторизация прямо в HTML?
• Сколько источников данных и какие их SLA?
• Сколько страниц, как часто обновляются, где живут пользователи?

2) Данные: BFF, кэш и теги инвалидации

Рендеринг держится на данных. Мы выносим агрегацию в BFF, а в Next.js используем fetch cache и теги. Для ISR тегируем фрагменты («/category/…», «/product/…»), привязываем вебхуки CMS/админки к точечной инвалидации, избегая «сносить весь сайт». Геокэш разнесён по регионам, ключи учитывают параметры запроса и локаль.

• «Горячие» блоки (цены/наличие) — клиентские запросы с кэшем запроса; «холодные» (описания) — на сервере/ISR.
• Прайс-чувствительные страницы — TTL в минутах; редакционный контент — регенерация по событию публикации.
• Вебхуки → очередь инвалидаций → батч-инвалидатор по тегам; повтор с экспоненциальным бэк-оффом.

3) Streaming: отдаём полезное раньше, тяжёлое — позже

Потоковая отдача позволяет показывать пользовательские элементы (шапка, навигация, skeleton-контент) сразу, а медленные блоки (рекомендации, аналитика, персональные панели) догружать по мере готовности. Мы разделяем экран на boundary-секции, прописываем fallback'и и тротлим перерендеры. Важный нюанс — «склейка» с кешем: стримим, но кэшируем готовые фрагменты там, где это возможно.

4) Гибридные страницы: персонализация без SSR-лавины

Частая ошибка — переводить всё на SSR «ради приветствия по имени». Мы оставляем HTML на ISR/SSG, а персональные куски (баланс, корзина, приветствие) догружаем из BFF после монтирования. Это даёт стабильный TTFB и снимает нагрузку, сохраняя качество UX. Для авторизованных потоков используем streaming-SSR частями (только где оправдано).

5) Метрики и эксплуатация

Мы измеряем TTFB, FCP, LCP, INP по сегментам «SSR/ISR/Streaming». На дашборде видно, где «горит»: медленные провайдеры, плохие регионы, долгие регенерации. Релизы привязываем к «спайкам» метрик, алерты на burn-rate SLO. Важная техническая рутина — наблюдать очереди регенераций и время жизни кэшей.

6) Частые анти-паттерны

• Глобальный SSR «на всякий случай» — дорогой TTFB и зависимость от бэкендов.
• ISR без тегов и вебхуков — регенерации «по расписанию» и устаревший контент.
• Streaming без fallback'ов — «мигающий» UI и дребезг состояний.
• Персонализация в HTML там, где хватает клиентских данных — лишняя сложность и стоимость.
• Ключи кэша без локали/регионов — неожиданные «перемешивания» данных.

Итог: стратегия рендеринга — это компромисс между свежестью, стоимостью и UX. Мы проектируем гибридные страницы на базе SSR/SSG/ISR и Streaming, опираясь на данные и кэш по тегам. Такой подход стабилизирует метрики и снимает нагрузку с инфраструктуры. Сроки/стоимость внедрения обсудим по контактам на сайте.