Мы 14 лет делали сайты на Битриксе. Потом перешли на Next.js — и вот что изменилось

У нас веб-студия с 2008 года. Первые 14 лет мы делали всё на 1С-Битриксе: корпоративные сайты, интернет-магазины, каталоги. Десятки проектов. Битрикс был нашим основным инструментом — мы знали его вдоль и поперёк, от компонентов до ядра.

А потом перестали. Не потому что «тренды» или «хайп» — а потому что клиенты стали жаловаться на скорость, мы стали тратить больше времени на борьбу с CMS, чем на решение задач бизнеса, а разработчики начали уходить, потому что не хотели писать на PHP.

За три года мы перевели на новый стек почти всех клиентов, а новые проекты начинаем сразу на нём. Стек: Next.js (фронтенд) + Express.js (бэкенд), всё на TypeScript. Расскажу без прикрас — что стало лучше, что стало сложнее, и какие цифры получили.

Битрикс — зрелый продукт. У него есть админка, готовые модули, интеграция с 1С, маркетплейс решений. Для задачи «сделать интернет-магазин с каталогом и корзиной» Битрикс по-прежнему работает. Но у нас накопились системные проблемы.

Скорость. Типичный корпоративный сайт на Битриксе отдаёт HTML за 150–300 мс (TTFB). С тяжёлым каталогом и несколькими компонентами на странице — 500+ мс. Это без учёта пинга. Пользователь ощущает это как «тормозит». Core Web Vitals на таких сайтах стабильно красные.

Хаос в файлах. Шаблоны компонентов Битрикса раскиданы по десяткам папок: /local/templates/, /local/components/, /bitrix/templates/ — и это только начало. Поиск нужного файла с шаблоном превращается в квест. А когда находишь — там PHP-файл на 2 000–3 000 строк, в котором намешаны HTML, PHP-логика, SQL-запросы и JavaScript. Рефакторить это невозможно, тестировать — тоже.

Кадры. Битрикс-разработчик — вымирающий вид. Мы полгода искали мидла, который хочет писать на Битриксе. Не нашли. Молодые разработчики учат React, TypeScript, Next.js — и идут туда, где это используется.

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

Фронтенд: Next.js с серверным рендерингом (SSR) и статической генерацией (SSG). App Router. Все компоненты типизированы.

Бэкенд: Express.js как API-сервер. Строгая типизация через TypeScript — от запроса до ответа. Никаких any, ранние возвраты, чёткие интерфейсы. Каждая ошибка видна в IDE ещё до запуска.

База данных: MySQL.

CMS: Собственная разработка. И это не «спартанская админка, которую дописывали на ходу» — мы целенаправленно спроектировали систему, взяв лучшее от всех CMS, с которыми работали за 17 лет.

Мы не стали брать готовую headless CMS (Strapi, Directus) — ни одна из них не закрывала наши потребности полностью. Вместо этого разработали свою, с фокусом на скорость работы контент-менеджера и гибкость для разработчика.

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

~15 типов полей для справочников. Текст, число, текстовый редактор TinyMCE, селект, чекбокс, дата, файл, изображение — и универсальное поле «ключ: значение». Последнее решило одну из главных болей интернет-магазинов на Битриксе.

Проблема характеристик товаров. В каталоге интернет-магазина могут быть сотни разных характеристик: вес, цвет, мощность, материал, размер, напряжение, количество оборотов... Если взять все уникальные наименования характеристик по всему каталогу — получается 500, 1 000, иногда до 2 000 полей. В Битриксе пришлось бы создавать все эти поля в инфоблоке, и каждое отображалось бы в карточке товара — даже если у конкретного товара заполнено только 5 из 2 000.

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

А на фронтенде это даёт умные фильтры: заходя в категорию каталога, покупатель видит только те фильтры, которые составлены из характеристик товаров этой категории и её подкатегорий. Характеристики, у которых в текущей выборке только одно значение — скрываются автоматически. Никакого мусора, только релевантные фильтры.

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

Журнал, заявки, SEO. Встроенный модуль журнала (статьи, новости), работа с заявками и заказами, API-интеграция с Google Search Indexing и Яндекс индексацией — страницы попадают в индекс за минуты, а не ждут переобхода.

Замеры с реальных проектов — корпоративные сайты и интернет-магазины с каталогами от 500 до 5 000 позиций.

TTFB (время до первого байта):

Разница в 5–10 раз. Страницы открываются мгновенно — пользователь это чувствует.

Lighthouse Performance (мобильные):

Размер страницы:

Для бизнеса это не абстрактные метрики. Это скорость загрузки, которую видит каждый посетитель. Это позиции в поиске — Google и Яндекс учитывают Core Web Vitals при ранжировании. Это конверсия — каждая секунда задержки снижает её на 7%.

В PHP-коде Битрикса типичная ситуация: компонент принимает массив $arResult, в котором может быть что угодно. Документации нет. Что в массиве — узнаешь из отладки или из исходников. Ошибки всплывают в продакшне, когда клиент видит белый экран.

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

Нет готового маркетплейса. В Битриксе 15 000 готовых решений — формы, слайдеры, интеграции, SEO-модули. В нашем стеке всё пишется руками или собирается из npm-пакетов. В долгосрочной перспективе это быстрее (нет «чёрных ящиков»), но на старте первого проекта заняло больше времени.

SEO при миграции. Перенос 1 000+ страниц без потери позиций — отдельный проект. Настройка nginx redirect map, 301-редиректы для каждого URL, canonical, sitemap, robots.txt. Мы потратили 2–3 недели чисто на SEO-миграцию для крупного каталога — и ни одну позицию не потеряли. Но без опыта потерять трафик при миграции очень легко.

Интеграция с 1С. Битрикс и 1С — штатная пара. В нашем стеке интеграцию писали через API, и это заняло больше времени.

Если сайт медленный и Lighthouse красный — стоит. Если планируете мобильное приложение или сложные интеграции — стоит. Если бизнес растёт и сайт должен масштабироваться — стоит. Если сайт-визитка на 5 страниц и работает нормально — не стоит, проще оставить как есть.

Мы не ненавидим Битрикс. Он решал задачи своего времени. Но для проектов, где важны скорость, качество кода, безопасность и возможность нанимать разработчиков — TypeScript-стек с Next.js + Express.js оказался объективно лучше. TTFB с 200 мс до 20 мс — это замеры с реальных серверов. Lighthouse с 50 до 95 — не магия, а серверный рендеринг и code splitting. А разработчики перестали увольняться — потому что работают с инструментами, которые им нравятся.