Серверный рендеринг или SPA: что выбрать для проекта

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

Сначала разделите два разных сценария

SSR формирует HTML на сервере для каждого запроса или для ограниченного набора условий. Браузер получает уже заполненную страницу, затем JavaScript «оживляет» её и подключает обработчики.

SPA отправляет браузеру оболочку приложения и JavaScript-бандлы. Данные и основной экран появляются после запуска кода и запросов к API. После первой загрузки переходы между разделами обычно происходят без полной перезагрузки документа.

Это не выбор между «быстрым» и «медленным» сайтом. SSR может тормозить из-за запроса к базе перед каждым ответом, а SPA — быстро показать каркас, но долго становиться интерактивным. Сравнивать нужно не технологические ярлыки, а путь пользователя от URL до полезного действия.

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

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

Четыре критерия, которые меняют решение

1. Как пользователь приходит на страницу

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

Внутри CRM, панели аналитики или рабочего места оператора пользователь чаще открывает приложение после авторизации. Поисковая индексация там не нужна, а большое количество локальных состояний и фильтров делает SPA удобным кандидатом.

2. Где находится стоимость рендера

У SPA часть работы переезжает на устройство пользователя: загрузка скриптов, разбор кода, построение интерфейса и запросы к API. На современном ноутбуке это может быть незаметно, на недорогом смартфоне и слабой сети — нет.

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

3. Насколько много состояния в интерфейсе

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

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

4. Что команда сможет поддерживать

SSR требует дисциплины на границе сервера и браузера. Код может выполняться в разных окружениях, доступ к window, document и локальному хранилищу нельзя бездумно использовать во время серверного рендера. Появляются вопросы кеширования персонализированных ответов, повторяемости данных и гидратации.

SPA проще развернуть как статические файлы, но усложняет клиентскую доставку: нужно следить за размером бандлов, маршрутизацией, авторизацией, API, загрузочными состояниями и обработкой ошибок сети.

Сравнение по цене решения

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

Как выбирать на практике

1. Опишите первый экран. Запишите, что должно быть видно без выполнения пользовательского действия. Для статьи, карточки товара или публичной услуги это обычно содержимое страницы. Для кабинета — каркас приложения и данные текущего пользователя.
2. Разделите публичные и закрытые маршруты. Публичные URL с трафиком из поиска чаще выигрывают от SSR или статической генерации. Авторизованные разделы, где важны фильтры и локальное состояние, чаще подходят для SPA-подхода.
3. Посчитайте серверную цену. Для SSR измерьте время ответа при холодном и прогретом кеше, число запросов к базе и потребление CPU. Для SPA измерьте размер JavaScript после сжатия, время загрузки на мобильной сети и время до первого действия.
4. Проверьте персонализацию. Страница с именем пользователя, корзиной или правами доступа не должна попасть в общий кеш. Если публичная и персональная части смешаны, разделите их на сервере или загружайте персональные данные отдельно.
5. Соберите прототип главного маршрута. Не сравнивайте пустые шаблоны. Возьмите реальный текст, изображения, запросы к API и форму. Только такой тест покажет, где возникает задержка.

Когда выбирать SSR

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

Когда выбирать SPA

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

Гибрид часто дешевле крайностей

Для интернет-магазина разумная схема может выглядеть так: каталог и карточки товаров получают серверный HTML, а корзина, фильтры и личный кабинет работают как клиентские участки. Для SaaS-продукта публичный сайт и документация рендерятся на сервере, а рабочее пространство остаётся SPA.

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

Что ломается у каждого подхода

Проблемы SSR

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

Проблемы SPA

• Слишком большой стартовый бандл. Пользователь скачивает код функций, которые ему не нужны на первом маршруте. Помогают разделение по маршрутам, отложенная загрузка и контроль зависимостей.
• Пустой экран при ошибке API. У каждого критичного запроса нужны состояния загрузки, ошибки и повторной попытки.
• Слабая доступность прямых URL. Сервер должен корректно отдавать маршрут приложения, а клиент — восстанавливать состояние после обновления страницы.

Ориентир по экосистеме для новых React-проектов — React 19 и Next.js 15, но сам выбор SSR или SPA не привязан к одному фреймворку. API рендера, правила кеширования и поведение маршрутизации нужно сверять с документацией конкретной версии.

Что делать дальше

Составьте таблицу маршрутов: источник перехода, необходимость SEO, персонализация, объём интерактивности и допустимое время первого действия. Затем соберите по одному реальному экрану в SSR- и SPA-варианте. В проде смотрите не только на среднее время ответа: отдельно измеряйте серверный ответ, время до полезного содержимого, время до интерактивности, размер загруженного JavaScript и долю ошибок API.