Нужен ли SPA локальному сервису или доставке: честное сравнение подходов
SPA — не признак современности, а компромисс: вы платите весом JavaScript и сложностью SEO за плавность переходов. Иногда сделка выгодна, часто нет.
Что технически означает SPA
Классический SPA отдаёт почти пустой HTML и собирает интерфейс в браузере из JavaScript-бандла. Навигация происходит без перезагрузки страницы, данные приходят отдельными запросами к API.
Плата за это — время до первой отрисовки: пользователь ждёт загрузку и выполнение бандла, прежде чем увидит хоть что-то. На быстром устройстве это десятые доли секунды, на бюджетном Android с 3G — несколько секунд белого экрана.
Современный компромисс — серверный рендеринг с гидратацией: HTML приходит готовым, а интерактивность добавляется поверх. В Next.js это поведение по умолчанию, и оно закрывает большинство сценариев без выбора между крайностями.
SEO: где именно возникают проблемы
Google умеет исполнять JavaScript, но делает это во вторую очередь и с задержкой. Для каталога с тысячами страниц это означает медленную и неполную индексацию, а для быстро меняющегося ассортимента — постоянное отставание индекса.
Мета-теги, canonical и hreflang, подставляемые на клиенте, часть роботов не увидит. Все критичные для SEO элементы должны быть в серверном HTML — это ключевое требование, а не рекомендация.
Отдельная типовая ошибка SPA — навигация без изменения URL или через хеш. Страницы, у которых нет собственного адреса, не индексируются и не отправляются ссылкой, что для локальной аудитории с Telegram особенно критично.
Когда SPA действительно оправдан
Личный кабинет, панель курьера, интерфейс оператора доставки, конструктор заказа с множеством зависимых полей, живая карта с перемещением исполнителя — всё это за авторизацией, индексировать нечего, а состояние сложное и меняется постоянно.
Признак, что SPA уместен: пользователь проводит в интерфейсе минуты и совершает десятки действий подряд. Тогда единовременная загрузка бандла окупается плавностью работы.
Признак обратного: пользователь приходит из поиска, смотрит одну-две страницы и уходит в звонок или заказ. Здесь загрузка бандла — чистые потери.
Типичный локальный сценарий: доставка еды
Разумная архитектура здесь смешанная. Публичная часть — меню, категории, страницы блюд, информация о доставке — рендерится на сервере или генерируется статически: это то, что индексируется и приводит трафик.
Корзина, оформление заказа и отслеживание статуса — интерактивная часть, живущая на клиенте с обращениями к API. Ей индексация не нужна, а отзывчивость критична.
Отдельно стоит рассмотреть Telegram Web App как второй интерфейс для повторных заказов: постоянные клиенты заказывают через мессенджер, а поисковый трафик приходит на серверные страницы сайта.
Цена решения в разработке и поддержке
Полноценный SPA требует отдельного API, продуманного управления состоянием, обработки офлайн-сценариев и ошибок сети. Это заметно больше кода, чем серверный рендеринг с формами, и дороже в поддержке.
Ориентир по рынку: сайт с серверным рендерингом и админкой — от 25 000 000 сум; проект с SPA-кабинетом, отдельным API и ролями — от 60 000 000 сум. Разница почти целиком в интерактивной части.
Учтите и стоимость ошибок: сломанная гидратация, рассинхронизация состояния и утечки памяти в долгоживущей вкладке — проблемы, которых на серверном рендеринге просто не существует.
Как принять решение
Разделите сайт на публичную и закрытую части и решайте по каждой отдельно. Смешанная архитектура — норма, а не компромисс, и современные фреймворки её прямо поддерживают.
Ключевой вопрос не «SPA или не SPA», а «какие страницы должны быть в индексе и как быстро они должны появляться на слабом соединении». Ответ на него определяет архитектуру почти однозначно.
Если подрядчик предлагает SPA для сайта услуг с формой заявки — попросите объяснить, какую задачу это решает. Чаще всего ответ сводится к удобству разработки, а платит за него скоростью пользователь в регионе на 3G.