Разработка на 1С-Битрикс: что стоит за выбором платформы
Мы часто наблюдаем: самая дорогая ошибка в Битрикс-проекте — неправильно выбранная редакция. Клиент покупает «Бизнес» за значительные средства, а через полгода выясняется, что для мультирегионального каталога с персональными ценами нужна «Бизнес Энтерпрайз». Разница не только в стоимости лицензии — это другая архитектура хранения данных, другой подход к кластеризации, другой потолок производительности. Миграция между редакциями на живом проекте с 80 000 товаров и 200 заказами в день — это не обновить лицензию, а полноценный инженерный проект на 3–6 недель. Экономия при правильном выборе на старте может составить существенную сумму только на лицензиях и расходах на миграцию. Подробнее о платформе можно узнать в Wikipedia.
Почему выбор редакции Битрикса — ключевое архитектурное решение?
Инфоблоки — основа Битрикса для хранения контента — имеют конструктивное ограничение. Каждое свойство элемента — это запись в b_iblock_element_property (EAV-модель, Wikipedia), и при фильтрации каталога MySQL собирает JOIN на каждое свойство, участвующее в фильтре. На 5 000 товаров это работает. На 50 000 — запросы к каталогу начинают занимать 3–8 секунд. На 200 000 — сайт просто ложится под любым фильтром.
Начиная с версии 17.0 в составе платформы появились highload-блоки: свойства хранятся не в EAV-таблице, а в отдельной плоской таблице с колонками. Фильтрация по 10 параметрам — один запрос без JOIN. Highload-блоки быстрее классических инфоблоков для фильтрации в 5–10 раз на каталогах от 50 000 товаров. Но они не поддерживают версионность, SEO-свойства из коробки и привычные события. Выбор между инфоблоками и highload — архитектурное решение на старте, и переделывать его на живом проекте дороже, чем потратить два дня на анализ в начале.
Мы начинаем каждый проект с аудита будущей нагрузки. Сколько товаров сейчас и сколько будет через год. Сколько одновременных посетителей. Какие фильтры нужны. Будет ли мультисклад. И уже от этого строим архитектуру, а не наоборот.
Типичные грабли в интернет-магазинах на Битрикс
Интернет-магазин — самый частый запрос. И самый недооценённый по сложности.
Модуль sale в Битрикс мощный, но запутанный. Корзина, заказ, оплата, доставка — четыре подсистемы, каждая со своим API. Начиная с версии 17.0 заказы перешли на новое ядро D7 (\Bitrix\Sale\Order), но половина модулей маркетплейса до сих пор работает через старый CSaleOrder. Результат — конфликты при кастомизации оформления заказа, особенно когда подключены сторонние модули доставки или оплаты.
Конкретный пример из практики: клиент подключил модуль доставки СДЭК и платёжный модуль ЮKassa. По отдельности — работают. Вместе — при определённой комбинации (самовывоз + оплата по QR) заказ создавался с нулевой стоимостью доставки, хотя на экране отображалась правильная сумма. Причина: оба модуля переопределяли обработчик OnSaleComponentOrderResultPrepared, и порядок вызова зависел от сортировки в b_module_to_module. Починка — полчаса. Поиск причины — два дня.
Ещё одна системная проблема — производительность страницы каталога. Стандартный компонент catalog.section выполняет от 40 до 120 SQL-запросов на одну страницу, в зависимости от количества свойств, SKU и ценовых типов. Включение композитного кэша помогает для анонимных пользователей, но авторизованные видят персональные цены — и каждый запрос идёт в базу. Решаем через предварительное кэширование ценовых матриц в Redis и отдачу их через AJAX после загрузки страницы.
Как избежать падения производительности при фильтрации каталога?
Оптимизированный кэш в Redis снижает время ответа на 60% по сравнению со стандартным кэшированием файлами. Мы используем тегированный кэш: при изменении цены или остатка одного товара сбрасывается только кэш, связанный с этим товаром, а не весь каталог. Это критично для интернет-магазинов с высокой частотой обновлений.
| Проблема | Стандартное решение | Наше решение | Выигрыш производительности |
|---|---|---|---|
| Фильтрация по свойствам (50 000+ товаров) | EAV-запросы с JOIN | Highload-блоки + индексы | В 5–10 раз |
| Персональные цены для авторизованных | Генерация на каждый запрос | Кэш ценовых матриц в Redis + AJAX подгрузка | Снижение времени ответа на 60% |
| Множественные SQL-запросы компонента catalog.section | Композитный кэш для анонимных | Кастомный компонент с агрегацией запросов | Снижение числа запросов в 2–3 раза |
Битрикс24, CRM и автоматизация бизнес-процессов
Отдельное направление — корпоративные порталы и CRM на базе Битрикс24. Тут своя специфика: REST API с лимитами в 2 запроса в секунду для коробочных версий (50 в секунду для «Энтерпрайз»), бизнес-процессы на визуальном редакторе, который ломается на сложных ветвлениях, и интеграции с внешними сервисами через вебхуки.
Мы часто связываем Битрикс24 с 1С:Предприятие. Контрагенты, счета, акты — двусторонняя синхронизация. Менеджер работает в CRM, бухгалтерия — в 1С, данные не расходятся. Технически это REST API + кастомные обработки на стороне 1С, с очередями на Redis для буферизации пиковых нагрузок.
Детали реализации обмена с 1С
Для синхронизации используем **CommerceML 2.0** через веб-сервисы. На стороне Битрикс24 создаём внешние обработчики на событии `OnCrmDealUpdate`, которые формируют XML-пакет и отправляют его в 1С через HTTP. В 1С настраивается асинхронный приём, чтобы не блокировать пользовательский интерфейс. Такой подход обрабатывает до 1000 сделок в сутки без потери данных.Безопасность: не опция, а необходимость
Модуль проактивной защиты (security) закрывает базовые векторы: WAF, защита сессий, контроль активности. Но он не спасёт от уязвимостей в кастомном коде или устаревших модулях маркетплейса. Мы проводим аудит безопасности отдельно: проверяем SQL-инъекции в кастомных компонентах, XSS в шаблонах, CSRF в формах, права доступа к файлам на сервере.
Частая находка — файлы бэкапов в публичной директории. bitrix/backup/ с полным дампом базы, доступный по прямому URL. Или bitrix/.settings.php с паролем от базы данных, который отдаётся при неправильной конфигурации nginx.
Если вы подозреваете уязвимости в своём проекте, закажите аудит безопасности — мы найдём и устраним их.
Миграция, поддержка, SEO-оптимизация
Миграция на Битрикс с других CMS (WordPress, OpenCart, самописные решения) — от 2 до 8 недель в зависимости от объёма контента и сложности логики. Критично сохранить URL-структуру и 301-редиректы, иначе SEO-позиции обнуляются.
Поддержка — это не только «починить баг». Обновления Битрикс выходят часто, и каждое обновление может сломать кастомные компоненты. Мы ведём реестр доработок по каждому проекту и перед обновлением проверяем совместимость. Для постоянной поддержки вашего проекта свяжитесь с нами — мы предложим оптимальный тариф.
SEO в Битриксе — отдельная история. Модуль seo умеет генерировать sitemap.xml, управлять мета-тегами и canonical. Но для серьёзного SEO нужна работа с микроразметкой Schema.org, оптимизация Core Web Vitals (LCP, CLS, INP), настройка серверного кэширования. Стандартный Битрикс отдаёт HTML с инлайновыми стилями и скриптами, что убивает PageSpeed — переписываем шаблоны для асинхронной загрузки и выносим CSS в отдельные файлы.
Что входит в работу по проекту на Битрикс
После завершения проекта вы получаете:
- Техническая документация: архитектура решения, описание кастомных компонентов, инструкции по развёртыванию.
- Доступы к системе управления, серверу и репозиторию (Git).
- Обучение администраторов: добавление товаров, работа с заказами, настройка свойств.
- Гарантийная поддержка на 1 месяц после запуска — исправление критических ошибок и консультации.
Как оцениваем проект
Каждый проект начинается с аудита текущего состояния (если есть действующий сайт) или анализа требований (если проект с нуля). Этапы:
- Сбор требований — что нужно бизнесу, какие интеграции, какой объём каталога
- Техническое проектирование — выбор редакции, архитектура данных, инфраструктура
- Оценка трудозатрат — декомпозиция до конкретных задач с часовой оценкой
- Разработка — итерациями по 2 недели с демо после каждой
- Тестирование — функциональное, нагрузочное, проверка безопасности
- Запуск и стабилизация — первые 2–4 недели после запуска в режиме усиленного мониторинга
Стоимость рассчитывается индивидуально после анализа требований. Обсудите проект с профильным специалистом — получите оценку и план работ.
| Тип проекта | Ориентировочные сроки |
|---|---|
| Корпоративный сайт | 3–6 недель |
| Интернет-магазин до 10 000 SKU | 6–12 недель |
| Крупный e-commerce с интеграциями | 3–6 месяцев |
| Внедрение Битрикс24 CRM | 2–8 недель |
| Миграция с другой CMS | 2–8 недель |
| Аудит безопасности и производительности | 3–10 дней |
Закажите аудит вашего проекта — мы определим редакцию, архитектуру и бюджет, а вы получите прозрачный план работ.