Веб-приложение или сайт: когда действительно нужен SPA

§ 01Разница на уровне архитектуры

Формально и сайт, и SPA открываются в браузере и показывают пользователю страницы. Технически под капотом работают совершенно разные механизмы.

Сайт — это коллекция статических или серверно-отрендеренных HTML-страниц. Каждая страница — отдельный HTML, сгенерированный на сервере или просто лежащий в виде файла. Переход между страницами — это полная перезагрузка: браузер идёт по ссылке, сервер отдаёт новый HTML, страница отрисовывается с нуля. Состояние между переходами не сохраняется без специальных усилий: чтобы помнить, что пользователь залогинен, нужны куки или localStorage.

SPA (Single Page Application) — это приложение, которое загружается один раз и потом живёт в браузере. Навигация между «страницами» — это не переход на новый URL с перезагрузкой, а смена состояния внутри одной JavaScript-программы. Данные подтягиваются с сервера через API (JSON по HTTP), а не в виде готовых HTML-страниц. Состояние между экранами сохраняется естественно: пользователь в одном месте ввёл данные, переключился на другой экран, вернулся — всё на месте.

Это принципиальная разница. Сайт — это набор документов. SPA — это программа. К ним применяются разные требования, разные подходы к разработке, разные критерии качества.

Есть и промежуточные варианты. Современные фреймворки (Next.js, Remix, SvelteKit, Nuxt) умеют комбинировать оба подхода: часть страниц отдаётся как статика с сервера, часть работает как SPA, навигация между ними бесшовная. Это называется «универсальным» или «гибридным» рендерингом. На практике в 2026 году чистых «классических сайтов» и чистых «клиентских SPA» почти не делают — все современные проекты живут где-то посередине.

§ 02Шесть сценариев, когда SPA действительно оправдан

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

1. Пользователь регулярно возвращается в один и тот же инструмент. Личный кабинет банка, admin-панель, рабочий планировщик, CRM. Здесь пользователь проводит минуты и часы, переключается между экранами, ожидает скорости и отзывчивости. Перезагрузка страницы после каждого клика ломает ощущение «инструмента».
2. Много состояния в UI. Открытые модалки, развёрнутые деревья, несохранённые черновики, выбранные фильтры, прогресс заполнения формы. Всё это надо помнить между действиями, и сайт на перезагрузках здесь постоянно теряет контекст.
3. Тяжёлый интерактив. Конструкторы, редакторы, калькуляторы с 20+ параметрами, drag-n-drop, интерактивные графики с зумом, онлайн-совместное редактирование. Это то, ради чего изначально придумали клиентский рендеринг: всё происходит мгновенно, без обращений к серверу за каждым движением.
4. Реальное время. Чаты, нотификации, live-дашборды с потоком событий, онлайн-аукционы, коллаборация нескольких пользователей на одной сущности. Для реального времени нужны долгоживущие соединения (WebSocket, SSE), которые легче поддерживать в SPA, чем на классических серверных страницах.
5. Сложная бизнес-логика на фронте. Форма заказа, которая рассчитывает цену с учётом 15 факторов по ходу ввода. Конструктор продукта с вариациями. Корзина с акциями, которые применяются в определённом порядке. Это логика, которая должна работать без задержек и без обращения к серверу на каждое изменение.
6. Приложение не нуждается в SEO. Внутренняя админка, закрытый портал, SaaS после логина, трекер задач. Поисковикам это не нужно индексировать, а значит можно смело рендерить всё на клиенте и не думать про SSR. В этих сценариях преимущества SPA раскрываются максимально.

Если в вашем продукте узнаётся 3+ пункта — сомнений быть не должно, это приложение, и пытаться сделать из него сайт — бесполезная экономия. Подробнее, что именно мы разрабатываю как веб-приложения и на каком стеке, — на странице услуги.

§ 03Когда хватит обычного сайта

Обратная ситуация встречается чаще, и она дороже для клиента. Заказчик слышит про SPA, читает про личные кабинеты крупных компаний, приходит с запросом на «современное веб-приложение» — а на самом деле ему нужен просто корпоративный сайт на 12 страниц. Разница в смете — 3–5 раз.

Признаки того, что хватит сайта:

• Основная задача — рассказать о компании, услугах, продуктах. Пользователь читает, иногда заполняет форму заявки.
• Страниц немного (до 30), большая часть — статический контент, редко меняющийся (раз в месяц и реже).
• Вход на сайт единоразовый: пользователь пришёл, нашёл нужное, ушёл. Не возвращается каждый день.
• SEO критичен. Вы хотите, чтобы ваши услуги находились в Яндексе и Google по коммерческим запросам. Сайт здесь изначально в лучшей позиции.
• Интерактив — только формы, каталог с фильтрами, иногда онлайн-калькулятор. Ничего сопоставимого с редактором или конструктором.

Здесь сайт не просто «достаточен» — он лучше SPA по ключевым параметрам: быстрее загружается на первый экран, лучше индексируется, дешевле в разработке, дешевле в поддержке. Делать из такого проекта SPA — значит ухудшить продукт ради иллюзии современности.

Типичная ошибка: «у нас будет личный кабинет, значит нужно SPA». Не обязательно. Если личный кабинет — это 3–5 экранов, которые пользователь посещает раз в месяц (посмотреть баланс, скачать отчёт), — это прекрасно живёт на обычном сайте с серверным рендерингом. SPA нужно, когда кабинет — это ежедневный рабочий инструмент.

Про диапазоны цен и что именно входит в обычный сайт по сравнению с веб-приложением — в отдельной статье сколько стоит сделать сайт.

§ 04Стек: Next.js, React, Svelte, tRPC

В 2026 году выбор стека для веб-приложения сузился до нескольких проверенных комбинаций. Разберу, что когда использую.

Next.js + React

Стандарт индустрии. Огромное сообщество, тонна готовых библиотек, предсказуемые паттерны. Поддерживает SSR, SSG, клиентский рендеринг — всё в одном фреймворке. Server Components позволяют рендерить часть компонентов на сервере без JavaScript на клиенте, что ускоряет первую загрузку.

Когда берём: если проект большой, команда растёт, нужна найм-фаза после сдачи (React-разработчиков найти проще, чем Svelte-разработчиков), нужна совместимость с ecosystem (много готовых интеграций, платёжных SDK, аналитики).

SvelteKit + Svelte 5

Современная альтернатива, которая пишется в 1.5–2 раза быстрее. Меньше кода, проще читается, быстрее собирается, bundle-размер меньше. Svelte 5 добавил runes — новую модель реактивности, которая решает большинство старых граблей.

Когда берём: небольшая команда, скорость разработки важнее, проект не требует специфической экосистемы React. Для MVP часто оптимальный выбор.

tRPC для типизированного API

Между фронтом и бэком, если оба на TypeScript. Вместо ручного описания REST-эндпоинтов tRPC автоматически выводит типы из серверного кода и даёт их клиенту. Меньше багов, меньше boilerplate, рефакторинг идёт автоматически по всей стопке.

Когда берём: full-stack проект на TypeScript, не нужно интегрироваться с публичным API для третьих лиц. Если API должен быть открытым для других клиентов (мобилка, интеграции) — лучше REST или GraphQL.

База, кэш, аутентификация

PostgreSQL — для большинства задач. Redis — если нужны очереди, кэш, реальное время или счётчики. Auth.js или Clerk — для быстрой аутентификации с соцсетями, 2FA, magic links. Для enterprise-проектов с SSO/SAML — WorkOS.

Чего избегаем

Чистый клиентский SPA без SSR — слишком медленная первая загрузка, слабая индексация. Angular для новых проектов — экосистема сжимается, найм сложнее. jQuery для нового кода в 2026 — знак технического долга на старте. Микрофронтенды для небольшой команды — сложнее, чем нужно.

§ 05Чек-лист миграции с сайта на веб-приложение

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

Последовательность шагов, которую мы прохожу на таких проектах:

1. Разделите сайтовый контент и приложение. Страницы «о нас», «услуги», «блог», «контакты» — остаются на сайтовом стеке (Astro, Next.js SSG, готовая CMS). Приложение с логикой, которое раньше было прикручено сбоку, — выносится в отдельную кодовую базу или отдельный раздел /app.
2. Сохраните URL-структуру сайта. Если блог был /blog/post-name, он должен остаться /blog/post-name. Потеря URL-ов = потеря SEO и внешних ссылок. 301-редиректы только в крайних случаях и минимально.
3. Определите границу сайта и приложения. Чаще всего это /app, /cabinet, /admin — раздел, в котором начинается логика, и до которого всегда нужна авторизация. До границы — публичный сайт, после — SPA.
4. Перенесите аутентификацию в приложение. На сайте вход был просто форнаш с session-cookie. В приложении — полноценный auth flow с JWT или session tokens, продление, refresh, logout.
5. Спроектируйте API. Если раньше формы отправлялись POST-запросами на классические endpoint'ы, теперь нужен структурированный API: JSON, типы, версионирование, документация. Лучше сделать это один раз правильно в начале миграции, чем переделывать через год.
6. Перенесите логику пошагово. Не пытайтесь за раз переписать всё. Выбираете один сценарий — например, форма заявки клиента — и реализуете её на новом стеке. Запускаете в прод, проверяете, что всё работает. Берёте следующий. Это называется strangler fig pattern — старая система постепенно замещается новой, без даунтайма и больших рисков.
7. Не забудьте аналитику. В SPA навигация не вызывает перезагрузку страницы, и стандартный Google Analytics / Яндекс.Метрика не отследит переходы. Нужно вручную вызывать pageview при смене маршрута — иначе метрики сломаются после миграции.
8. Заложите тесты на критический путь. На сайте можно было жить без автотестов — на SPA это серьёзный риск. Минимум — E2E-тесты на логин, основной сценарий пользователя, оплату. Playwright или Cypress, 30–50 тестов покрывают 90% регрессий.

По срокам миграция обычно занимает в 1.5–2 раза больше, чем писали бы приложение с нуля — потому что надо поддерживать старую и новую систему параллельно. Но риск меньше: вы не выключаете прод в один момент, а постепенно перекладываете.

Для стартапов, которые только начинают разрабатывать продукт, полезно сразу заложить SPA-архитектуру и не мигрировать потом. Про этот подход для ранней стадии — в статье MVP за 4–6 недель.

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

Самые частые вопросы клиентов до начала конкретной работы.