Вопрос звучит как технический, а решается как финансовый. «Делать на готовой CMS или писать на фреймворке» — это выбор не между хорошим и плохим инструментом, а между двумя разными распределениями затрат по времени. CMS дешевле на старте и дороже на нестандартной логике. Фреймворк наоборот. Вся задача в том, чтобы до начала работ понять, сколько в проекте будет нестандартного, — и это единственный критерий, который действительно работает.
Что покупается вместе с CMS
Готовая система даёт пласт работы, которого просто не видно, пока его не приходится делать руками:
- Админка с ролями и правами, журналом изменений и восстановлением удалённого
- Каталог с категориями, свойствами, фильтром, поиском и сортировками
- Корзина, оформление заказа, статусы, скидки и купоны
- Готовые модули оплаты и доставки, которые уже прошли через чужие ошибки
- Обмен с учётными системами из коробки — у 1С-Битрикс это штатный CommerceML
- Редактор контента, к которому контент-менеджер привык и не задаёт вопросов
- Рынок исполнителей: любой подрядчик возьмётся за типовую доработку
Последний пункт в разговоре о технологиях почти не звучит, а по факту он самый дорогой. Сайт на распространённой CMS можно передать другой студии за один разговор. Это снижает риск для владельца сильнее, чем любые архитектурные достоинства.
Что CMS забирает взамен
Платой за готовые механизмы становится навязанная структура данных. В CMS сущности описаны заранее: товар, свойство, раздел, пользователь, заказ. Пока ваша предметная область в эти сущности укладывается, всё хорошо. Как только появляется что-то своё, начинается натягивание.
Как это выглядит на практике. Нужен подбор товара по правилам совместимости — в модели «товар и свойства» связи многие-ко-многим с условиями не предусмотрено, и её изображают дополнительными справочниками поверх штатных. Нужна цена, зависящая от объёма, региона и договора одновременно — ценовые группы такого не умеют, и расчёт переезжает в код обработчика. Нужен конфигуратор с валидацией состава — это уже отдельное приложение, которое просто живёт внутри CMS.
Каждая такая надстройка работает, но у неё два свойства: она медленнее, чем решение на своей схеме данных, и она ломается при обновлении ядра. Второе — отдельная статья расходов, о которой вспоминают через год.
Признак, что CMS выбрана неправильно: больше половины разработки уходит не на функциональность, а на обход того, как система устроена внутри.
Второй неочевидный пункт — производительность на нестандартных выборках. Универсальная модель хранения свойств означает, что фильтр по пяти параметрам превращается в запрос с несколькими соединениями и группировками. На тысяче товаров это незаметно, на сотне тысяч — заметно сразу, и лечится кешем, индексами и отдельными таблицами, то есть той же самой работой, которую на фреймворке сделали бы один раз в схеме. Про то, как это выглядит со стороны скорости, мы писали в разборе Core Web Vitals для каталога.
Что даёт фреймворк
Фреймворк — Laravel, Symfony, что-то ещё — не даёт ни админки, ни каталога. Он даёт инструменты: маршрутизацию, слой работы с базой, миграции схемы, очереди, планировщик, тесты, кеширование, валидацию. Всё прикладное пишется.
Что получается в обмен:
- Схема базы под вашу предметную область, с нормальными индексами и без универсальных таблиц свойств
- Полный контроль над запросами: видно, что выполняется и сколько это стоит
- Миграции в репозитории — структура базы меняется управляемо и одинаково на всех контурах
- Очереди и расписание как штатная часть: тяжёлый обмен, выгрузки и письма не держат запрос пользователя
- Тесты на бизнес-логику, которые имеет смысл писать, потому что логика своя
- API как первичный интерфейс — тот же код обслуживает сайт, мобильное приложение и внешние системы
И главное: обновление фреймворка обновляет библиотеку, а не ваш сайт. Нет ядра, которое перезаписывает файлы, нет модулей сторонних авторов, конфликтующих между собой при обновлении. Цена этого — отсутствие готовых модулей вообще.
Что фреймворк забирает
Честный список того, что придётся сделать руками и что обычно недооценивают в оценке:
- Админка: списки с фильтрами, формы, загрузка картинок, права, журнал действий
- Редактирование контента так, чтобы с этим работал человек без разработчика
- Импорт и экспорт данных, обработка больших файлов, отчёт об ошибках строк
- SEO-слой: метатеги по шаблонам, canonical, карта сайта, редиректы, разметка
- Корзина и оформление заказа со всеми пограничными случаями
- Подключение оплаты и доставки с нуля, включая возвраты и фискализацию
Это не недели, а месяцы, если делать полноценно. Поэтому аргумент «на фреймворке получится быстрее» верен ровно до того момента, как в требованиях появляется контент-менеджер и каталог. Детали, которые тут всплывают — от фискального чека до возврата, — разобраны в статье про приём платежей на сайте: в CMS это настройка модуля, на фреймворке — разработка.
Второй риск — зависимость от конкретных людей. Код на стандартном фреймворке читаем любым разработчиком этого стека, но только если он написан стандартно. Своя архитектура «как у нас принято», без тестов и без документации, превращается в то же самое, от чего убегали: систему, которую знает один человек.
Признаки, по которым выбирают
Берите CMS, если:
- Проект — типовой магазин или корпоративный сайт: каталог, корзина, контент, формы
- Нужен обмен с 1С, и структура номенклатуры в учёте обычная
- Контентом будут заниматься сотрудники, а не разработчик
- Срок до запуска короткий, а бюджет ограничен
- Важно, чтобы сайт можно было передать любому подрядчику
Берите фреймворк, если:
- Бизнес-логика и есть продукт: конфигуратор, расчёт стоимости по правилам, подбор по совместимости, сложная логистика
- Данные приходят из нескольких систем и требуют своей модели, а не той, что навязана
- Нужны нетиповые роли и сценарии: кабинеты с разными правами, согласования, многоуровневый доступ
- Нагрузка на выборки высокая, и скорость каталога — требование, а не пожелание
- На том же коде должно работать мобильное приложение или внешняя интеграция
- Учётная система нестандартная, и обмен всё равно пишется с нуля
Если проект попадает в оба списка — а так бывает часто, — решает соотношение. Типовая витрина плюс один нестандартный модуль делается на CMS. Нестандартная логика плюс простая витрина делается на фреймворке. Пятьдесят на пятьдесят — повод рассмотреть третий вариант.
Третий вариант: разделить слои
Схема, при которой данные и контент живут в одной системе, а витрина — в другой. Классический случай: каталог и заказы ведутся в учётной системе и CMS, а сайт отдаёт страницы самостоятельным приложением, читая данные по API. Витрина получается быстрой и свободной в вёрстке, а редакторы продолжают работать в привычном интерфейсе.
Платой становится вторая система, которую тоже надо держать живой. Это осмысленно, когда требования к скорости и дизайну высокие, а редакционный процесс уже выстроен. Это плохо заканчивается, когда разделение сделано по моде: тогда вместо одной системы получаются две, и обе требуют поддержки.
Считаем цену владения, а не разработки
Сравнение по сумме сметы почти всегда уводит в неверную сторону. Считать надо по статьям и на горизонте в три года — именно столько обычно живёт сайт до следующего крупного пересмотра.
- Лицензия. У коммерческой CMS она платная на старте и требует продления для получения обновлений; у фреймворка её нет
- Разработка. На CMS меньше там, где функциональность типовая, и больше там, где её обходят
- Обновления. На CMS это регулярная работа: ядро, модули, проверка на копии; на фреймворке — реже и предсказуемее
- Хостинг. Тяжёлая CMS требовательнее к ресурсам, но разница в деньгах обычно невелика
- Доработки. Главная статья, и она целиком зависит от того, насколько ваша логика совпала с моделью системы
- Смена подрядчика. На типовой CMS это недели, на своём коде — зависит от качества кода и документации
Третий пункт недооценивают систематически. Обновления — не разовая задача, а ежемесячная: пропущенные обновления превращаются в уязвимости, а накопленные за два года — в отдельный проект по миграции. Закладывать их в бюджет нужно сразу, независимо от выбора.
Правильный вопрос не «что лучше», а «где в нашем проекте будет больше работы: в том, чтобы построить типовое, или в том, чтобы обойти чужую модель данных».
Как решать это на практике
Процедура, которая даёт ответ за один день, а не за три совещания:
- Выписать всю нестандартную логику отдельным списком — всё, чего нет в обычном магазине
- По каждому пункту оценить два варианта: сделать на CMS и сделать на фреймворке
- Сложить оценки и добавить к варианту с фреймворком админку, импорт и SEO-слой
- Добавить к варианту с CMS лицензию и регулярные обновления на три года
- Посмотреть на разницу: если она в пределах погрешности, выбирать CMS — у неё меньше риск передачи
- Отдельно ответить на вопрос, кто будет вести контент и какой интерфейс ему нужен
Последний пункт решает больше, чем кажется. Сайт, который невозможно наполнять без разработчика, перестаёт обновляться через два месяца после запуска — и дальше не важно, насколько хороша была архитектура.
Этот список, по сути, часть технического задания: он требует проговорить требования до того, как выбран инструмент. Что в задании должно быть кроме него, разобрано в статье про техническое задание на сайт.
Чего делать не стоит
- Выбирать систему до того, как описаны требования — тогда требования начинают подгоняться под инструмент
- Писать свою CMS с нуля: это худший из вариантов, потому что сочетает отсутствие готовых модулей с отсутствием сообщества
- Брать тяжёлую коммерческую платформу под сайт из восьми страниц ради «надёжности»
- Брать фреймворк потому, что он современнее, при полностью типовых требованиях
- Считать, что переписать потом будет легко: перенос каталога, адресов и позиций — отдельный проект
Последний пункт стоит дороже всех остальных вместе. Смена платформы — это не только код, но и сохранение адресов, редиректы, индексация и позиции. Как это делается без потерь, мы разбирали в статье про переезд сайта без потери позиций.
Мы работаем в обоих направлениях: делаем магазины и каталоги на 1С-Битрикс и WordPress и пишем проекты на фреймворке там, где логика не укладывается в готовую модель. Решение принимается на этапе требований и обосновывается цифрами, а не предпочтениями. Как устроен процесс и что входит в работу, смотрите на странице разработки сайтов; для проектов со сложной выборкой и подбором — каталоги и порталы, для типового магазина с обменом — сайт на 1С-Битрикс. Если выбор стоит между двумя конкретными CMS, а не между CMS и фреймворком, есть отдельный разбор: Битрикс или WordPress для магазина.
