Как понять, что сайту нужно веб-приложение, а не обычный сайт

Частая ситуация: заказчик приходит с запросом «сделайте сайт», а по факту ему нужно то личный кабинет, то фильтры с сохранением состояния, то что-то, что реагирует мгновенно без перезагрузки страницы. Разберу конкретные признаки, по которым можно понять это ещё до разговора с разработчиком — без лишней теории.

Вадим Лукьянцев Frontend-разработчик, Краснодар · 5 минут на чтение

Что вообще считается «обычным сайтом», а что — «веб-приложением»

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

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

Главный признак — сколько действий совершает пользователь внутри сайта

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

Здесь легко ошибиться в обе стороны: заказать простую вёрстку под задачу, которая требует логики на фронте, или переплатить за архитектуру там, где хватило бы обычных страниц.

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

Если у проекта есть роли пользователей (клиент и администратор видят разное), состояния, которые нужно сохранять между визитами (корзина, избранное, история заказов, статус доставки) — нужен полноценный фронт с логикой и бэкенд, который эту логику обслуживает. Обычная вёрстка страниц такую задачу не решает в принципе, вне зависимости от того, насколько качественно она сделана.

Признак: насколько часто меняются данные и нужна ли им мгновенная реакция интерфейса

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

Если данные меняются редко и мгновенная реакция не критична — того же результата можно добиться и обычной вёрсткой с минимальным JavaScript поверх.

Когда обычного сайта хватит с запасом

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

Что происходит, если выбрать неправильно

Недосайт: заказали простую вёрстку под задачу, которая на деле требовала логики на фронте, — в итоге на страницу навешивают JS-костыли поверх, что дороже и хуже по качеству, чем сразу заложить архитектуру под задачу. Пересайт: заказали SPA под простую визитку — переплатили за ненужную сложность и получили лишние риски по индексации без реальной выгоды от архитектуры, которая тут не нужна.

Не уверены, какой вариант подходит именно вашему проекту?

Разберу задачу и честно скажу, нужен ли вам полноценный веб-функционал или хватит обычной вёрстки — без попытки продать то, что не нужно.

Обсудить фронтенд-проект Обсудить проект

FAQ по теме

Можно ли начать с обычного сайта и потом дорастить до веб-приложения?
Да, но это не всегда бесшовный процесс — зависит от того, насколько изначальная архитектура допускает расширение. Если планы на рост есть уже сейчас, дешевле заложить это на старте, чем переделывать позже.

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

Как понять разницу, если я не разбираюсь в технологиях совсем?
Ориентир простой: если посетитель у вас на сайте только читает и уходит — это сайт; если он что-то делает и система это запоминает — это уже веб-приложение. Остальное можно обсудить на созвоне.

Нужно ли веб-приложение интернет-магазину?
Не всегда — небольшой магазин с редко обновляемым каталогом отлично работает и на обычной вёрстке или CMS. Веб-приложение оправдано, когда нужны сложные фильтры, персонализация или личный кабинет с историей заказов.

Вадим Лукьянцев Об авторе — нажмите, чтобы раскрыть

Веб-разработчик, Краснодар. Делаю сайты под ключ на Vue/Nuxt и React/Next, вёрстку по макетам из Figma и PSD, сайты на WordPress и SEO-продвижение — сам, без субподрядчиков.

Работаю с 2GIS, Яндекс.Бизнесом, самозанятость оформлена официально с 2024 года. С клиентами по всему Краснодарскому краю и удалённо по России.