SSG vs SSR vs SPA: что выбрать AI-конструктору сайтов

Что такое каждый из подходов

SSG (Static Site Generation) — сайт собирается на этапе сборки. Каждая страница превращается в готовый HTML-файл с уже подставленным контентом. Этот файл попадает в CDN (Cloudflare, Fastly, наша Vzlyot Cloud) и отдаётся посетителю за миллисекунды.

SSR (Server Side Rendering) — каждая страница собирается сервером в момент запроса. Сервер получает запрос, идёт в базу данных, рендерит React (или другой шаблонизатор) в HTML и отправляет посетителю. Контент свежий, но нужен работающий бэкенд.

SPA (Single Page Application) — сервер отдаёт пустой HTML и большой JavaScript-бандл. Бандл скачивается и сам строит интерфейс в браузере. Любой переход между страницами происходит без полной перезагрузки.

Скорость для пользователя

SSG безоговорочно выигрывает по скорости первой загрузки. Контент уже готов, лежит в CDN, отдаётся за 50–200 мс. Никаких запросов к базе, никакого ожидания JavaScript. SSR требует работы сервера и базы — обычно 200–800 мс на запрос. SPA в плане первой загрузки — самый медленный: пустой HTML, потом скачать бандл (200–800 КБ), потом выполнить JS, потом сходить за данными — итог 1,5–4 секунды до первого осмысленного экрана на средних мобильных.

Видимость в поиске

SSG и SSR одинаково хорошо индексируются: в первом ответе сервера уже готовый HTML. Все боты — Googlebot, YandexBot, GPTBot, PerplexityBot — видят полный текст и заголовки сразу.

SPA проигрывает: Googlebot умеет «дорисовывать» страницы JavaScript, но делает это с задержкой и не для всех URL. YandexBot и LLM-боты часто индексируют SPA как пустые страницы. Для маркетинговых сайтов — это критично.

Стоимость инфраструктуры

SSG — самый дешёвый: статика на CDN стоит копейки. Один мощный CDN-аккаунт обслуживает десятки тысяч пользователей в час без напряжения. SSR требует работающих серверов, которые масштабируются под нагрузку — это дороже и сложнее в эксплуатации. SPA по цене сопоставима с SSG (тот же статический CDN), но добавляется отдельный API-сервер для данных.

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

• Маркетинговые сайты, лендинги, сайты-визитки, блоги, документация.
• Каталоги услуг, портфолио, страницы курсов и мероприятий.
• Небольшие интернет-магазины (карточки товаров можно перегенерировать каждые несколько часов).
• Контент-сайты, где данные меняются не каждую секунду.

Когда лучше SSR

• Страницы зависят от данных в реальном времени (билеты на рейс, котировки, наличие на складе с минутной точностью).
• Страницы персонализированы под каждого пользователя (рекомендации в маркетплейсе по просмотрам).
• Каталог из десятков тысяч страниц, где пересборка SSG занимает часы.

Когда оправдан SPA

SPA — правильный выбор для интерфейсов приложений: личных кабинетов, дашбордов, чатов, онлайн-редакторов. Им не нужно индексироваться, важна мгновенная реакция на действия пользователя без перезагрузки. Сама панель Взлетим — это SPA.

Для публичной маркетинговой части у SPA преимуществ перед SSG практически нет — только проблемы с поиском и медленной первой загрузкой.

Почему AI-конструкторы массово делают SPA

Это технически проще. AI генерирует React-код, фреймворк собирает его в SPA-бандл, готово. Никакого пререндера, никакой сборки HTML под каждую страницу — экономия времени на стороне разработчиков конструктора. Цена этого решения — пустые страницы для поисковиков и медленная загрузка у посетителя.

Реализовать SSG в AI-конструкторе сложнее: нужен Vite-плагин (или Next-аналог) пререндера, который проходит по всем страницам сгенерированного сайта и сохраняет каждый как отдельный HTML. Внутри Взлетим этот плагин — ключевая часть нашей сборки.

Гибридные стратегии

В реальном проекте часто используется гибрид: маркетинговые страницы — SSG, кабинет пользователя — SPA, отдельные «горячие» страницы (наличие билетов, личные рекомендации) — SSR. Это даёт лучшее из всех миров: индексация и скорость для публичной части, гибкость для приложения.

Так работает почти весь современный веб большой громкости: VK, Avito, Booking, многие новостные порталы. Сайты, которые делает Взлетим, — это SSG-первая часть, на которой посетитель видит контент моментально. Внутренние интерактивные части можно добавить поверх через JavaScript уже после загрузки.