Single Page Application перезагружает не всю страницу при переходе между разделами, а только меняет часть DOM через JavaScript - сервер после первой загрузки отдаёт данные, а не готовый HTML. За практику на React, Vue и Angular я собрал десятки таких интерфейсов, и почти на каждом проекте всплывал один и тот же вопрос от заказчика: точно нужен SPA, или хватит обычного сайта на WordPress или Tilda? Ответ зависит не от моды на фреймворки, а от задачи, бюджета и того, кто смотрит на сайт - живой человек из поиска или пользователь, который уже вошёл в личный кабинет.
Что такое single page application и чем оно отличается от обычного сайта
Обычный многостраничный сайт на каждый клик отправляет запрос на сервер и получает в ответ новую HTML-страницу целиком - так работают WordPress, Tilda и большинство лендингов. Single page application грузит один HTML-шаблон один раз, а дальше меняет содержимое через JavaScript: клиент запрашивает у API только JSON с данными, рендерит их локально и подменяет адрес в браузере через History API, без перезагрузки страницы целиком.
Разница ощущается в интерфейсе сразу: переходы между разделами SPA происходят почти мгновенно, без белого экрана и повторной загрузки стилей и скриптов. Но за эту скорость платят усложнением архитектуры - нужен отдельный бэкенд с API, авторизация через токены вместо сессий, и отдельное внимание к тому, как страницы индексируются поисковиками, потому что первый HTML часто приходит почти пустым, а весь контент дорисовывается уже в браузере.
Когда одностраничное приложение оправдано на практике
SPA имеет смысл там, где пользователь работает с интерфейсом подолгу и в одном состоянии: личный кабинет, CRM, дашборд, конструктор, чат. Три признака, что задача действительно под SPA-архитектуру:
- много взаимодействий на одном экране без перезагрузки - фильтры, сортировки, drag-and-drop;
- данные меняются в реальном времени, и пользователь держит несколько состояний интерфейса одновременно;
- бэкенд уже отдаёт (или может отдавать) данные через REST или GraphQL API, а не готовый HTML.
Собирал CRM-панель на React для логистической компании - там диспетчер держит на экране одновременно таблицу заявок, карту доставки и статус синхронизации с СДЭК, и каждое обновление статуса не должно перерисовывать всю страницу. Обычный сайт с перезагрузкой на каждый клик здесь не выдержал бы темп работы: диспетчер обрабатывает по 40-60 заявок за смену, и лишняя секунда на каждый переход за месяц выливается в часы простоя.
Похожая история с BI-дашбордами на Vue.js - SPA там собирает данные из нескольких источников и обновляет графики без перезагрузки, пока пользователь листает фильтры по датам и сравнивает периоды. Перегружать такую задачу обычным сайтом с перезагрузкой страницы на каждый фильтр бессмысленно - интерфейс будет ощущаться как древний веб-сервис из нулевых.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Когда обычный многостраничный сайт выигрывает у SPA
Для лендинга, блога, корпоративного сайта или интернет-магазина с несколькими десятками товаров SPA почти всегда лишняя нагрузка. Причины простые:
- Сайт из 5-10 страниц не нуждается в клиентском роутинге - обычный HTML и так рендерится быстро.
- Основной трафик идёт из поиска, а значит SEO важнее плавности переходов между разделами.
- Стоимость и сроки разработки на Tilda или WordPress ниже в разы, а результат для такой задачи не хуже.
Для интернет-магазина с оплатой через эквайринг Т‑Банка и доставкой через СДЭК я обычно собираю связку WooCommerce на WordPress или магазин на Tilda с кастомными скриптами под корзину и статусы заказов - этого хватает на 200-500 товаров, и поисковик индексирует карточки без танцев с рендерингом на клиенте. Доработка конкретного блока на Tilda стоит от 3 000 ₽, комплексная интеграция с CRM и эквайрингом - от 40 000 ₽. Часть таких доработок я уже собрал в готовые скрипты для Tilda, которые ставятся за день-два вместо месяца разработки с нуля.
SPA под тот же магазин обойдётся от 150 000 ₽ и потребует отдельного бэкенда, тогда как интернет-магазин под ключ на привычном стеке стартует от 80 000 ₽ и уже включает админку, оплату и доставку.
Иногда фронтенд вообще не нужен - если задача сводится к внутреннему процессу вроде обработки заявок или уведомлений менеджеру, дешевле собрать Telegram-бота на aiogram (от 30 000 ₽) или цепочку в n8n (от 25 000 ₽), чем городить SPA с личным кабинетом ради одной формы и списка задач.
SEO и скорость: сравниваю SPA-архитектуру с обычным сайтом по цифрам
Ключевое отличие проявляется в метриках, а не в ощущениях. Вот как это выглядит на реальных проектах:
| Параметр | MPA (WordPress/Tilda) | SPA без SSR |
|---|---|---|
| Первая отрисовка (FCP) | 0.5-1.5 сек | 1.5-3 сек, пока грузится JS-бандл |
| Переход между разделами | 0.3-1 сек, с перезагрузкой | 50-150 мс, без перезагрузки |
| Индексация поисковиком | Из коробки | Нужен SSR (Next.js/Nuxt) или prerender |
| Вес начальной загрузки | 200-500 КБ | 500 КБ - 2 МБ (JS-бандл) |
Без серверного рендеринга Google и Яндекс видят в SPA почти пустой div, пока не выполнится JavaScript, - не каждый краулер готов его дожидаться, особенно если скрипты грузятся медленно на мобильном интернете. Поэтому для проектов, где важен органический трафик, я или ставлю Next.js с SSR поверх React, или вообще не завожу SPA-архитектуру и делаю лендинг на Next.js как гибрид - от 80 000 ₽, с быстрой отдачей HTML и без потери в интерактивности там, где она реально нужна.
Сколько стоит и сколько времени занимает разработка single-page приложения
По деньгам разброс большой, потому что SPA почти никогда не работает без отдельного бэкенда:
- Веб-сервис или SaaS на SPA-архитектуре - от 150 000 ₽, срок от 3-4 недель на рабочий MVP.
- CRM или админ-панель на React - от 100 000 ₽.
- Дашборд или BI-интерфейс на Vue.js - от 90 000 ₽.
- API под такой фронтенд отдельно на Laravel - от 100 000 ₽, если бэкенда ещё нет вовсе.
На рынке цены на похожие SPA-проекты у студий и фрилансеров держатся в диапазоне 150 000-500 000 ₽ в зависимости от сложности авторизации и интеграций - я ориентируюсь на нижнюю границу для проектов без избыточной архитектуры, но не занижаю её в ущерб срокам тестирования.
Отдельная статья расходов - поддержка. SPA обновляется чаще, чем статичный сайт: меняется API, ломается совместимость библиотек, накапливаются зависимости фронтенда. Техподдержку беру от 15 000 ₽/мес, и для SPA-проектов это обычно не разовая доработка, а именно абонемент - раз в квартал вылезает что-то из-за обновления браузеров или npm-пакетов.
Частые ошибки при выборе между SPA и обычным сайтом
Три ситуации, с которыми сталкивался не раз. Клиент заказывает SPA для сайта-визитки из 4 страниц, потому что это выглядит современно, - а потом полгода не может нормально продвинуть сайт в поиске, потому что специалист по SEO бьётся с рендерингом контента на клиенте.
Команда собирает SPA под интернет-магазин без SSR, теряет органический трафик на карточках товаров, а потом достраивает Next.js поверх готового React-приложения - это дороже и дольше, чем сразу спроектировать с серверным рендерингом.
Обратная ошибка - тащат тяжёлую бизнес-логику личного кабинета на WordPress с десятком плагинов, потому что сайт уже есть, и получают интерфейс, который тормозит на каждом клике и требует перезагрузки, чтобы обновить статус заявки. В такой ситуации обычно советую выносить именно эту часть в отдельное SPA-приложение, а витрину и блог оставлять на обычном движке - это и есть гибридная архитектура, где каждый инструмент отвечает за свою часть задачи.
Когда нужен не сайт, а сервис
SaaS / SPA
от 300 000 ₽
Подробнее →Частые вопросы
Нужен ли SPA для интернет-магазина?
В большинстве случаев нет - WooCommerce на WordPress или магазин на Tilda с доработками под эквайринг и СДЭК закрывают задачу дешевле и с рабочим SEO из коробки. SPA для магазина оправдан, только если это маркетплейс с личным кабинетом, сложной фильтрацией по десяткам параметров и нагрузкой, которую обычный движок не потянет.
Можно ли сделать SPA-часть внутри сайта на Tilda?
Да, но частично - на Tilda реально встроить блок с клиентским рендерингом вроде калькулятора, личного кабинета или чата через кастомный скрипт, который подключается к отдельному API. Сам конструктор остаётся многостраничным, а SPA-логика живёт в конкретном блоке страницы.
SPA хуже индексируется в Яндексе и Google?
Без серверного рендеринга - да, потому что краулер видит почти пустой HTML до выполнения JavaScript. С SSR на Next.js или Nuxt разница с обычным сайтом почти стирается, но эту настройку нужно закладывать в проект с самого начала, а не пристраивать потом поверх готового приложения.
Сколько времени занимает переход с обычного сайта на SPA?
Для сайта из 10-15 страниц с базовой логикой - от 3 до 6 недель, если переносить контент и настраивать API параллельно. Если нужен ещё и бэкенд под данные, которые раньше жили в базе CMS, срок растёт до 2-3 месяцев, потому что API проектируется практически с нуля.