SPA, MPA или SSR: как выбрать подход к рендерингу веб-приложения

По данным Google Web Dev (Jason Miller & Addy Osmani), выбор стратегии рендеринга — один из ключевых архитектурных решений для веб-приложения: он определяет скорость первой загрузки, индексируемость поисковиками и сложность инфраструктуры. HTTP Archive Web Almanac фиксирует взрывной рост фреймворков с поддержкой SSR и SSG — Next.js, Nuxt, SvelteKit — на фоне насыщения рынка классическими SPA. При этом по данным MDN, SPA по-прежнему доминируют в закрытых продуктах: дашбордах, SaaS-инструментах, личных кабинетах. Суть вопроса не в том, «какой подход модный», а в том, какой подходит конкретному продукту.

В этой статье мы разберём SPA, MPA и SSR: как каждый из них работает, чем отличается по SEO, скорости (Core Web Vitals) и стоимости, и как выбрать правильный подход для разработки веб-приложения под ключ. Материал для владельцев продуктов и технических заказчиков, которые стоят перед этим выбором до старта.

Что такое рендеринг веб-приложения и почему выбор подхода важен

Рендеринг веб-приложения — это процесс превращения кода (HTML, CSS, JS, данных) в страницу, которую видит пользователь. Ключевой вопрос: где и когда это происходит — на сервере до отправки браузеру или в браузере пользователя после загрузки JS-бандла.

От ответа на этот вопрос напрямую зависят три бизнес-критичных показателя:

• SEO и индексация. Поисковые боты видят только тот HTML, который получают в HTTP-ответе. Если контент появляется после выполнения JS — есть риск, что бот его не увидит или проиндексирует с задержкой.
• Скорость загрузки (Core Web Vitals). TTFB (Time to First Byte), FCP (First Contentful Paint), LCP (Largest Contentful Paint) и TTI (Time to Interactive) напрямую зависят от того, где собирается HTML.
• Стоимость разработки и инфраструктуры. Разные подходы требуют разного стека, команды и серверных ресурсов.

CSR, SSR и статика: три способа собрать страницу

Таксономия подходов к рендерингу включает несколько вариантов:

• CSR (Client-Side Rendering) / SPA — сервер отдаёт почти пустой HTML, весь контент строит JavaScript в браузере.
• SSR (Server-Side Rendering) — сервер формирует полный HTML при каждом запросе, браузер получает готовый контент.
• SSG (Static Site Generation) — HTML собирается один раз при деплое, раздаётся как статика с CDN.
• ISR (Incremental Static Regeneration) — гибрид SSG и SSR: статические страницы обновляются по расписанию или по запросу без полного ребилда.
• MPA (Multi-Page Application) — классический серверный подход, каждая страница — отдельный запрос к серверу с полной перезагрузкой.

Что происходит в браузере: TTFB → FCP → TTI (и почему это влияет на бизнес)

Пользователь открывает страницу — и начинается цепочка событий:

1. TTFB (Time to First Byte) — сколько времени прошло до получения первого байта от сервера.
2. FCP (First Contentful Paint) — момент, когда в браузере появляется первый видимый контент.
3. LCP (Largest Contentful Paint) — когда отрисован главный блок страницы (hero, заголовок, изображение).
4. TTI (Time to Interactive) — когда страница реагирует на клики и взаимодействие.
5. INP (Interaction to Next Paint) — задержка реакции на действие пользователя, входит в Core Web Vitals с 2024 года.

Google использует LCP, CLS и INP как сигналы ранжирования. Медленный LCP прямо снижает позиции в поиске и конверсию: по данным Google, рост LCP на 1 секунду снижает вероятность конверсии на ~12%.

SPA — клиентский рендеринг (CSR)

Как работает SPA (пустой HTML + JS-бандл + client-side routing)

При первом запросе сервер отдаёт минимальный HTML-скелет — буквально пустой <div id="root"></div> — и ссылки на JavaScript-бандл. Браузер скачивает бандл, парсит его и только после этого строит DOM и рендерит контент. Все переходы между страницами происходят без перезагрузки: JavaScript перехватывает клик, меняет URL через History API и перерисовывает нужный компонент. Это обеспечивает ощущение «нативного» приложения.

Типичные фреймворки: React, Vue, Angular (в режиме CSR), Svelte (без SSR).

Плюсы и минусы SPA

• Плюс — скорость навигации после загрузки. Переходы между разделами мгновенные — данные подгружаются через API без перезагрузки страницы.
• Плюс — богатый UX. Анимации, оффлайн-режим (PWA), реактивный UI — всё это нативно для SPA.
• Плюс — чёткое разделение фронтенд/бэкенд. Бэкенд — чистый REST/GraphQL API, фронтенд — отдельная кодовая база. Удобно для больших команд.
• Минус — плохой первый экран. До загрузки и выполнения JS пользователь видит пустую страницу. FCP и LCP страдают, особенно на медленных устройствах.
• Минус — SEO-риски. Googlebot рендерит JS, но помещает страницы в Rendering Queue с задержкой в дни. Bing и Yandex могут вовсе не ждать — и получат пустой HTML.
• Минус — тяжёлый JS-бандл. Крупные SPA доставляют 1–3 МБ JavaScript на первой загрузке. Даже с code splitting это ощутимо на мобильных сетях.
• Минус — сложность SEO-метатегов. Open Graph, canonical, title для соцсетей и ботов нужно динамически менять через JS или использовать prerendering-сервис.

Когда выбирать SPA (закрытые ЛК, дашборды, SaaS за авторизацией)

SPA — правильный выбор, когда:

• продукт находится за авторизацией (личный кабинет, CRM, аналитический дашборд) — SEO не нужен;
• приоритет — богатый интерактивный UX: drag-and-drop, real-time обновления, сложные формы;
• команда сильна в React/Vue и хочет чёткого разделения фронтенд/бэкенд;
• приложение работает как desktop-alternative: идёт в PWA или Electron.

MPA — классический серверный подход

Как работает MPA (страница = ответ сервера, полная перезагрузка)

В классической MPA (Multi-Page Application) каждый переход — это новый HTTP-запрос к серверу. Сервер обрабатывает запрос, берёт данные из БД и возвращает готовый HTML. Браузер перезагружает страницу целиком. Это поведение характерно для традиционных сайтов на PHP (Laravel), Python (Django/Flask), Ruby on Rails, а также для CMS типа WordPress.

На стороне клиента JavaScript используется точечно: для валидации форм, слайдеров, небольших виджетов — но не управляет маршрутизацией.

Плюсы и минусы MPA

• Плюс — SEO из коробки. Поисковый бот получает полноценный HTML в ответе — индексация простая и предсказуемая.
• Плюс — быстрый FCP и TTFB при правильной настройке. Первый байт приходит с полным контентом, никакого ожидания JS.
• Плюс — простота разработки. Зрелые фреймворки (Laravel, Django) с встроенным ORM, шаблонизатором и маршрутизацией позволяют быстро строить функциональные продукты.
• Плюс — низкий порог входа и большая экосистема. PHP/Python-разработчиков много, готовых пакетов — тысячи.
• Минус — полная перезагрузка страницы. При переходах браузер перезагружает всё — хедер, футер, шрифты. Ощущение менее «приложенческое», больше «сайтовое».
• Минус — ограниченный интерактив. Богатый UI требует либо AJAX-костылей, либо встроенного фронтенд-фреймворка (Alpine.js, Livewire, HTMX).
• Минус — масштабирование нагрузки. При высоких RPS классический рендеринг на сервере дороже, чем раздача статики с CDN.

Когда выбирать MPA (контентные/e-commerce/SEO-first сайты)

MPA — оптимальный выбор, когда:

• SEO — первостепенный приоритет: контентный сайт, блог, новостной портал, создание сайта для бизнеса;
• команда специализируется на конкретном серверном стеке (PHP, Python, Ruby);
• проект — корпоративный сайт или лендинг с умеренным интерактивом;
• нужен быстрый запуск MVP без отдельной фронтенд-команды;
• бюджет ограничен и важно минимизировать инфраструктуру.

SSR — серверный рендеринг с гидратацией

SSR, SSG и ISR: в чём разница

SSR (Server-Side Rendering) — сервер генерирует HTML при каждом запросе в реальном времени. Пользователь всегда получает свежие данные, но сервер нагружен больше.

SSG (Static Site Generation) — HTML генерируется один раз при деплое для всех страниц и раздаётся с CDN. Максимальная скорость, минимальная серверная нагрузка, но обновление контента требует ребилда.

ISR (Incremental Static Regeneration) — компромисс: страницы собираются статически, но автоматически регенерируются через заданный интервал (например, каждые 60 секунд) или по on-demand запросу. Реализован в Next.js, Nuxt, Astro.

Все три можно комбинировать в рамках одного проекта: главная — SSG, каталог товаров — ISR, страница корзины — SSR, личный кабинет — CSR.

Гидратация и её цена (TTI, «uncanny valley», прогрессивная/streaming-гидратация)

SSR решает проблему первого экрана: браузер получает готовый HTML и мгновенно рендерит контент (низкий FCP). Но страница ещё не интерактивна — кнопки не реагируют на клики. Чтобы добавить интерактивность, браузер скачивает и выполняет тот же JS-бандл, что и в SPA, и «гидратирует» DOM, привязывая обработчики событий.

Разрыв между FCP и TTI называют «uncanny valley» — страница выглядит загруженной, но не реагирует. Это раздражает пользователей и влияет на INP.

Современные фреймворки решают это через:

• Streaming SSR (React 18, Next.js 13+) — HTML отправляется потоком: самый важный контент приходит первым, менее важные блоки — позже через Suspense.
• Прогрессивная гидратация — интерактивность подключается поочерёдно, начиная с видимых компонентов, а не для всей страницы сразу.
• Partial Hydration / Islands Architecture (Astro, Fresh) — гидратируются только интерактивные «острова», статические блоки остаются чистым HTML.

Плюсы и минусы SSR

• Плюс — быстрый FCP и хорошая индексация. Бот и пользователь получают полноценный HTML немедленно — лучший результат для SEO и воспринимаемой скорости.
• Плюс — свежие данные при каждом запросе. Персонализированный контент, актуальные цены, динамические каталоги — SSR обновляет их в реальном времени.
• Плюс — лучший LCP. Главный контентный блок рендерится сервером — браузер не ждёт JS.
• Минус — серверная нагрузка. Каждый запрос требует рендеринга — нагрузка на сервер в разы выше, чем при раздаче статики.
• Минус — сложность инфраструктуры. Нужен Node.js-сервер (или edge workers), кэширование на уровне CDN, правильная инвалидация кэша.
• Минус — TTI выше, чем у SSG. Гидратация добавляет задержку перед интерактивностью, хотя Streaming SSR её сокращает.
• Минус — стоимость. SSR-инфраструктура дороже в эксплуатации, чем статические CDN-страницы.

Когда выбирать SSR (SEO + интерактив: маркетплейсы, медиа, витрины)

SSR — правильный выбор, когда нужно сочетание SEO и динамичности:

• интернет-магазин или маркетплейс с большим каталогом и часто меняющимися ценами/остатками;
• медиапортал или новостной сайт с актуальными данными;
• продуктовый лендинг с A/B-тестами и персонализацией;
• любой SEO-ориентированный продукт с богатым интерактивом.

SPA vs MPA vs SSR: сравнительная таблица

Критерий	SPA (CSR)	MPA	SSR / SSG / ISR
Где рендерится HTML	Браузер (после загрузки JS)	Сервер (при каждом запросе)	Сервер (при запросе или на билде)
TTFB	Низкий (статика)	Зависит от сервера	Выше при SSR; низкий при SSG+CDN
FCP / LCP	Медленный (ждём JS)	Быстрый	Быстрый
TTI	После загрузки бандла	Почти сразу	После гидратации JS
SEO из коробки	Слабый (нужен prerender)	Отличный	Отличный
Сложность разработки	Средняя (фронтенд+бэкенд API)	Низкая	Высокая (SSR) / Средняя (SSG)
Стоимость инфраструктуры	Низкая (статика + API)	Средняя	Высокая (SSR) / Низкая (SSG+CDN)
Типовые сценарии	Дашборды, SaaS, ЛК	Корпоративные сайты, блоги	E-commerce, медиа, маркетплейсы
Примеры фреймворков	React, Vue, Angular (CSR)	Laravel, Django, Rails	Next.js, Nuxt, Astro, SvelteKit

Как выбрать подход под ваш проект

Выбор подхода к рендерингу — не техническое, а продуктовое решение. Его принимают исходя из четырёх критериев.

Критерий 1 — SEO и индексация

Если проект живёт за счёт органического трафика — исключайте чистый SPA сразу. Для открытого контента (блог, каталог, лендинг, новостной сайт) нужен SSR, SSG или классическая MPA. Исключение — prerendering-сервисы (Prerender.io, динамический рендеринг), но это дополнительная инфраструктура и компромисс.

Если контент за авторизацией и SEO не нужен — SPA оптимален.

Критерий 2 — производительность и Core Web Vitals (FCP, LCP, TTI, INP)

Для публичных страниц с требованиями к Core Web Vitals и позициям в Google: SSG даёт лучший LCP (CDN + предсобранный HTML), SSR — хороший FCP при динамическом контенте. Чистый SPA исторически проигрывает по LCP на медленных устройствах.

Если TTI и INP критичны — оцените стоимость гидратации: Streaming SSR и прогрессивная гидратация (React 18+, Nuxt 3) существенно сокращают разрыв FCP→TTI.

Критерий 3 — сложность и стоимость разработки/поддержки

MPA на Laravel/Django — самый быстрый старт и наименьшая сложность. SPA требует фронтенд-команды и отдельного API. SSR — самая сложная инфраструктура, но Next.js/Nuxt значительно снижают порог. SSG — простота MPA + скорость CDN, но подходит только для относительно редко меняющегося контента.

Критерий 4 — команда, стек и сроки

Технически правильный подход бесполезен, если команда его не знает. Если у вас сильные PHP-разработчики — Laravel MPA или Laravel + Inertia.js (гибрид MPA/SPA) даст предсказуемый результат быстрее, чем переход на Next.js. Учитывайте доступность специалистов и временные рамки.

Быстрая матрица выбора (по типу продукта)

Тип продукта	Рекомендация	Почему
Лендинг / промо-сайт	SSG или MPA	Статика с CDN — максимальная скорость, минимум затрат
Корпоративный сайт / блог	MPA (Laravel/Django) или SSG	SEO-first, умеренный интерактив, быстрый запуск
Интернет-магазин / e-commerce	SSR + ISR (Next.js/Nuxt)	SEO + динамические данные (цены, остатки) + масштаб
Медиапортал / новости	SSR или ISR	Актуальный контент + SEO + высокий трафик
Личный кабинет / дашборд / SaaS	SPA (React/Vue)	За авторизацией, богатый UI, SEO не нужен
Маркетплейс с SEO + интерактивом	Гибрид: SSR/ISR + CSR для ЛК	Разные части продукта требуют разного рендеринга

Типичные ошибки при выборе рендеринга

Эти ошибки встречаются в реальных проектах и стоят дорого — в деньгах или SEO-позициях.

• SPA для контентного SEO-сайта. Команда выбирает React SPA для блога или каталога, потому что «умеем React». Через полгода оказывается, что страницы плохо индексируются, позиции падают, а добавление SSR требует переработки архитектуры. Стоимость исправления — выше, чем правильный выбор на старте.
• SSR там, где хватило бы SSG. Для блога или маркетингового сайта, где контент меняется редко, разворачивают полноценный SSR с Node.js-серверами. Это лишняя нагрузка и расходы: SSG на Netlify или Cloudflare Pages стоил бы несравнимо дешевле.
• Игнорирование INP и «uncanny valley» при SSR. SSR с наивной гидратацией даёт красивый FCP, но страница не реагирует на клики несколько секунд. Пользователь кликает кнопку — ничего. Google учитывает INP в Core Web Vitals. Решение: Streaming SSR, прогрессивная гидратация, или Islands Architecture.
• Забытый prerender для соцсетей и мессенджеров. Чистый SPA не формирует Open Graph теги при первом запросе — превью ссылок в Telegram, WhatsApp, Facebook выглядят пустыми. Боты этих платформ не рендерят JS. Нужно либо SSR, либо специализированный prerendering для ботов.
• Гибридный подход без стратегии кэширования. SSR + ISR работают отлично, но без правильной стратегии CDN-кэширования (Cache-Control, stale-while-revalidate) сервер получает лишнюю нагрузку, а пользователи видят устаревший контент. Кэширование в SSR-проектах — отдельная дисциплина.
• Выбор подхода без учёта команды. Теоретически правильный Next.js SSR, реализованный PHP-разработчиками без опыта, даст худший результат, чем хорошо сделанный Laravel MPA. Стек должен совпадать с компетенциями команды или учитывать время на онбординг.

Частые вопросы

Чем SPA отличается от SSR простыми словами?

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

Подходит ли SPA для SEO?

Для открытого SEO-контента SPA рискован: Googlebot рендерит JavaScript, но делает это с задержкой (Rendering Queue), что замедляет индексацию. Bing и Yandex могут вовсе не ждать. Если SEO критичен, выбирайте SSR или SSG. SPA оправдан для закрытых разделов за авторизацией — дашборды, личные кабинеты.

Что выбрать для интернет-магазина — SSR или MPA?

Для интернет-магазина оптимален SSR с ISR для каталога (Next.js, Nuxt): страницы категорий и карточек товаров генерируются на сервере или статически — быстрый FCP и отличная индексация. MPA на Laravel/Django тоже работает для малого ассортимента. Чистый SPA для e-commerce почти никогда не выбирают.

Обязателен ли Next.js или Nuxt для SSR?

Нет. SSR можно реализовать вручную на Express/Node.js или через любой серверный фреймворк. Но Next.js и Nuxt дают готовую инфраструктуру: маршрутизацию, ISR, Streaming SSR, оптимизацию изображений и деплой на edge — из коробки.

Можно ли комбинировать подходы в одном проекте?

Да, это распространённая практика. Next.js и Nuxt поддерживают гибридный рендеринг: маркетинговые страницы — SSG, каталог с частыми обновлениями — ISR или SSR, личный кабинет — CSR. Такая «островная» архитектура позволяет оптимизировать производительность и SEO именно там, где это важно.

Что дешевле в разработке и поддержке?

MPA на зрелом фреймворке (Laravel, Django) обычно дешевле всего на старте. SPA сложнее в разработке (нужен бэкенд API + фронтенд-команда), но дешевле в поддержке UI при частых изменениях. SSR дороже в эксплуатации; SSG/ISR снижает затраты за счёт CDN и минимальной серверной нагрузки.