Выбор между SPA, SSR, SSG, потоковым рендерингом и островной архитектурой редко бывает чисто техническим. На самом деле это решение о том, где платить за скорость первого экрана, как работать с SEO, насколько сложным становится контур доставки и кто отвечает за проблемы гидратации в промышленной эксплуатации.
Эта глава полезна тем, что превращает спор о модели рендеринга в набор измеримых компромиссов: TTFB, LCP, кэшируемость HTML, цена персонализации и сложность диагностики. Так разговор о рендеринге перестаёт быть спором вкуса и становится архитектурным выбором под конкретный продукт.
Для интервью и ревью это важный материал, потому что именно стратегия рендеринга соединяет фронтенд с edge, CDN, композицией серверной стороны и ограничениями клиентской среды выполнения в одной точке принятия решений.
Практическая польза главы
Практика проектирования
Разделяйте маршруты по классам: публичные страницы, каталог, checkout, личный кабинет и документация часто требуют разных моделей рендеринга.
Качество решений
Оценивайте выбор по TTFB, LCP, кэшируемости HTML, размеру бандла, цене персонализации и сложности диагностики.
Аргументация на интервью
Объясняйте выбор как цепочку: класс маршрута, ограничения SEO и задержки, модель данных, кэширование, гидратация и путь миграции.
Формулировка компромиссов
Фиксируйте, где платится основная цена: на сервере, CDN, устройстве пользователя или в операционной сложности команды.
Контекст
Производительность фронтенд-платформы
Модель рендеринга влияет на воспринимаемую скорость раньше, чем большинство локальных UI-оптимизаций.
определяет, где появляется первый полезный экран: на сервере, на , на пограничном слое или только после загрузки клиентского кода. Поэтому спор между , , , островной архитектурой, серверными компонентами и частичным пререндерингом на деле превращается в разговор о задержке, SEO, стоимости платформы и сложности эксплуатации.
Правильный вопрос звучит не как «какой режим лучше», а как «для какого класса маршрутов какой режим окупает свои компромиссы».
В этой главе рендеринг рассматривается вместе с , , , , , , , частичным пререндерингом, , , LCP, размером бандла, персонализацией и инвалидацией кэша.
Карта моделей рендеринга
Одна страница может отдавать минимальную оболочку, готовый HTML, статический файл, поток HTML или частично интерактивные острова. Переключайте режимы, чтобы увидеть, где появляется первый полезный экран и где возникает главная сложность.
HTML на сервере
Сервер формирует HTML для запроса, браузер быстро видит содержимое, а затем клиентский код делает страницу интерактивной.
Вход
Запрос маршрута
Сервер получает URL, cookies, заголовки и контекст пользователя.
Рендеринг
Серверная среда
Собирает данные, шаблон и начальный HTML для конкретного запроса.
Ответ
Готовый HTML
Поисковая система, предпросмотр ссылки и пользователь получают содержимое до полной загрузки клиента.
Интерактивность
Гидратация
Клиентский код связывает HTML с состоянием и обработчиками событий.
Архитектурный смысл
Когда выбирать
- Публичные страницы с требованиями к SEO и первому экрану.
- Важны предпросмотры ссылок, быстрый HTML и контролируемая персонализация.
- Команда готова поддерживать серверную среду и диагностику гидратации.
SSR быстрее отдаёт содержательный HTML, но клиентский код всё равно остаётся частью цены: тяжёлая гидратация может ухудшить пользовательский опыт.
Где какой режим окупается
SPA
Серверная часть остаётся тонкой: вся логика интерфейса живёт в , а сервер только отдаёт почти пустой HTML и бандл.
Где уместно
Внутренние продукты, рабочие кабинеты после входа и сценарии с богатой интерактивностью, где индексируемый HTML не является главным ограничением.
За что платим
Первый экран, и восстановление состояния после обновления страницы никто за вас не сделает — за ними придётся следить отдельно.
Серверный рендеринг (SSR) / потоковый SSR
даёт содержательный HTML в первом ответе: это помогает индексации, предпросмотру ссылок и первому экрану.
Где уместно
Маркетплейсы, медиа, страницы поиска и смешанные публично-приватные маршруты, где важны SEO и быстрый первый видимый экран.
За что платим
Растёт сложность серверной среды, , диагностики и персонализации.
SSG / ISR
хорошо ложится на , а позволяет обновлять готовые страницы без полной пересборки сайта.
Где уместно
Документация, базы знаний, маркетинговые страницы и каталоги с предсказуемой частотой обновления.
За что платим
Без явной политики свежести, правил обновления и границы между общим HTML и персонализированными блоками страница рано или поздно покажет устаревшие данные.
Островная архитектура (islands) / частичная гидратация
Страница остаётся в основном HTML, а оживают только интерактивные зоны через , поэтому в браузер уезжает заметно меньше кода.
Где уместно
Контентные страницы, лендинги и справочные материалы с несколькими интерактивными блоками.
За что платим
Цена — устойчивые границы виджетов, понятный обмен данными между островами и отдельная диагностика для каждого клиентского острова.
Современные модели: серверные компоненты и частичный пререндеринг
Четыре режима выше отвечают на вопрос «когда и где появляется HTML». Серверные компоненты React и частичный пререндеринг добавляют две новые оси, поэтому их удобно разбирать рядом с потоковым и островами: первая модель меняет место исполнения компонента, вторая — гранулярность границы между статикой и динамикой.
Серверные компоненты React (RSC)
Меняют не момент рендера, а место исполнения: выполняется только на сервере — на сборке или на запросе — и не отправляет свой код в браузер. Клиент получает готовый результат и ссылки на клиентские бандлы.
- Серверные компоненты асинхронные: данные читаются прямо во время рендеринга, без отдельного клиентского запроса и водопадов.
- Граница помечается директивой клиентского кода; гидратируются только клиентские компоненты, поэтому объём клиентского JavaScript и цена гидратации падают.
- Серверное дерево передаётся не как HTML, а как сериализованную серверных компонентов: она стримится и встраивается в клиентское дерево, а код самих компонентов в неё не попадает.
- Нужен фреймворк с серверной поддержкой React (например, App Router в Next.js); модель стабильна начиная с React 19.
Частичный пререндеринг (PPR)
Снимает выбор «весь маршрут статический или динамический»: один маршрут отдаёт статическую оболочку сразу, а персональные и свежие участки достримивает в выделенные «дырки» в том же -ответе.
- Граница статики и динамики — это Suspense: заглушка уезжает в статическую оболочку, а содержимое обёрнутого блока подтягивается на запросе, когда готово.
- Построен поверх серверных компонентов: оболочка приходит как HTML при первой загрузке и как сериализованная при клиентской навигации.
- Решение «статика или динамика» принимается на уровне границы Suspense, а не всего маршрута, — это гибрид внутри одной страницы.
- В Next.js частичный пререндеринг стабилизирован в версии 16 и включается флагом cacheComponents; прежний экспериментальный experimental.ppr убран.
Для архитектуры это продолжение двух правил главы: серверные компоненты бьют по цене на уровне модели, а частичный пререндеринг переносит границу «общий кэшируемый каркас против персонализации» с уровня маршрута на уровень отдельного блока.
Сигналы для выбора
- Насколько страница должна быть полезной до входа и до загрузки тяжёлой .
- Есть ли жёсткие требования к SEO, предпросмотру ссылок в соцсетях и публичному первому экрану.
- Можно ли кэшировать HTML на или ответ слишком персонализирован.
- Как часто меняется контент и насколько критично показать слегка устаревший HTML.
- Готова ли команда поддерживать серверную среду, и гибридную маршрутизацию.
Примеры классов маршрутов
Публичная посадочная страница
Статическая генерация (SSG) или серверный рендеринг (SSR)Главные ограничения здесь обычно SEO, быстрый первый экран, предпросмотр ссылок и дешёвая доставка через сеть доставки контента (CDN).
Каталог и поиск
Серверный рендеринг (SSR), потоковый SSR или гибридПользователь должен быстро увидеть структуру, но фильтры, наличие и рекомендации часто требуют свежих данных.
Оформление заказа и критический сценарий
Серверный рендеринг (SSR) + клиентская интерактивностьПервый экран важен, но цена ошибки выше: состояние корзины, валидация и платёжные шаги должны быть контролируемыми.
Личный кабинет или панель управления
Одностраничное приложение (SPA) или гибрид после входаИндексируемость обычно вторична, зато важны состояние, быстрые переходы, кэш запросов и реакция на действия пользователя.
Документация и база знаний
Статическая генерация (SSG) / инкрементальная регенерация + островаБольшая часть страницы статична, а интерактивными могут быть поиск, песочницы, копирование команд и фильтры.
Связано
Content Delivery Network (CDN)
HTML-кэш, устаревший ответ с фоновой повторной проверкой и путь инвалидации часто определяют реальную цену серверного рендеринга (SSR) и статической генерации (SSG) сильнее, чем сам фреймворк.
Архитектурные правила
Стратегия выбирается по классу маршрута, а не для всего продукта
Посадочная страница, поиск, оформление заказа и личный кабинет живут под разными ограничениями. Один глобальный режим рендеринга редко оптимален для всех .
Гидратация — отдельный эксплуатационный риск
Расхождение между серверным HTML и клиентским деревом часто проявляется только в реальных условиях: часовой пояс, локаль, фича-флаги, A/B-тесты и поздний приход данных.
Ранняя персонализация ломает дешёвое HTML-кэширование
Чем раньше в ответ попадают пользовательские блоки, тем сложнее использовать . Часто выгоднее отдать общий каркас и добавить персонализацию после первого отображения.
Сеть доставки контента (CDN) и пограничный слой являются частью архитектуры рендеринга
, ключ кэша, предварительная загрузка и путь инвалидации нужно обсуждать вместе с моделью рендеринга, а не после выбора фреймворка.
Загрузка данных задаёт реальную границу модели
Если экран зависит от многих источников, одних слов «» или «» мало. Важно решить, где работает , что можно показать частично и какие данные можно временно отдать в слегка устаревшем виде.
Компромиссы моделей рендеринга
Операционный чек-лист
- У каждого ключевого маршрута есть целевые значения , LCP, размера бандла и времени до интерактивности.
- Описаны ключи кэша, срок жизни HTML, правила и путь инвалидации.
- Есть мониторинг ошибок гидратации, различий локали, фича-флагов и позднего прихода данных.
- Понятно, кто владеет режимом рендеринга каждого класса маршрутов и меняет его при росте продукта.
- Для медленных блоков спроектированы скелетон, показ слегка устаревших данных, частичный ответ и понятное сообщение об ошибке.
Типичные антипаттерны
Выбрать один режим рендеринга для всего продукта
Так команда быстро начинает оптимизировать посадочную страницу, оформление заказа и внутренний кабинет одними и теми же правилами, хотя ограничения у них разные.
Считать серверный рендеринг (SSR) только инструментом для SEO
Серверный HTML влияет ещё и на первый экран, предпросмотр ссылок, кэширование, стоимость персонализации и операционную сложность.
Не учитывать цену гидратации
Быстрый HTML не спасает страницу, если после него браузер долго выполняет клиентский код и блокирует взаимодействие.
Проектировать кэш сети доставки контента (CDN) после выбора фреймворка
Ключ кэша, инвалидация и персонализация определяют реальную стоимость и не меньше, чем сама среда выполнения.
Практический вывод
Источники и материалы
Связанные главы
- Архитектура фронтенд-приложения: оболочка, функциональные модули и общее ядро - задаёт модульную основу, поверх которой выбираются разные модели рендеринга для разных классов маршрутов.
- Производительность фронтенд-платформы - показывает, как выбор рендеринга превращается в LCP, бюджет бандла и реальный пользовательский опыт.
- Content Delivery Network (CDN) - добавляет контекст пограничного кэша, инвалидации и для , и гибридной доставки.
- Периферийные вычисления (edge computing): архитектура и компромиссы - помогает понять, когда логику рендеринга выгодно переносить ближе к пользователю.
- Слой данных во фронтенде: REST, GraphQL, бэкенд для фронтенда (BFF) и оркестрация - объясняет, как модель рендеринга зависит от загрузки данных, агрегации и загрузчиков маршрутов.