Разработка сайта на 1С-Битрикс

Разработка сайта на 1С-Битрикс

Когда проект стартует на Битриксе, архитектурное решение первого дня определяет стоимость поддержки на три года вперёд. Один инфоблок под каталог с 30 свойствами — и через год b_iblock_element_property разрастается до миллионов строк, CIBlockElement::GetList выполняется 4 секунды, а фасетный индекс не помогает, потому что свойства-привязки не попали в b_catalog_sm_*. Переделать структуру на проде — это переписать шаблоны компонентов, перестроить фильтры, пересоздать SEO-правила. Дешевле спроектировать один раз.

Инфоблоки, Highload, D7 ORM — выбор хранения

Это не абстрактный вопрос — от него зависит, какие компоненты будут работать «из коробки», а какие придётся писать с нуля.

Обычные инфоблоки хранят свойства в EAV-модели: таблица b_iblock_element_property, одна строка — одно значение. Для каталога на 5К товаров с 10 свойствами это 50К строк, MySQL переварит. Для 80К товаров с 25 свойствами — 2 миллиона строк, JOIN-ы при фильтрации начинают стоить секунды. Зато инфоблоки дают штатную SEO-обвязку, визуальный редактор, встроенные компоненты каталога.

Highload-блоки — плоская таблица, одна колонка на свойство. Индексы ложатся ровно, фильтрация по 200К записей — 30-80ms. Но нет привычного catalog.section, нет наследования свойств от разделов, нет штатного SEO-модуля. Для справочников (города, бренды, единицы измерения) — обязательно. Для основного каталога — зависит от объёма и сложности фильтрации.

D7 ORM через Bitrix\Main\ORM\Data\DataManager — для сущностей, которые не лезут ни в инфоблоки, ни в Highload. Заявки с десятью связями, кастомные логи, агрегации по периодам. Полный контроль, но админку рисуешь сам.

Чем Битрикс отличается от WordPress и Laravel

WordPress — тоже EAV через wp_postmeta, но без штатного e-commerce уровня sale. WooCommerce — плагин, не ядро. Битрикс даёт модуль catalog с торговыми предложениями (SKU), типами цен, складским учётом, обменом с 1С через CommerceML. Для компании, которая живёт в 1С:Предприятие, это аргумент, который перевешивает всё остальное.

Laravel — фреймворк, не CMS. Полная свобода архитектуры, но каталог, корзина, права доступа, обмен с 1С — пишешь с нуля. На проекте с бюджетом 4-6 месяцев и командой из 3 человек Laravel оправдан. Для корпоративного сайта с каталогом, который нужен через 2 месяца, — Битрикс быстрее. Не лучше и не хуже — быстрее при типовых задачах.

Принципиальное отличие — компонентный подход. Битрикс-компонент (bitrix:catalog.section, bitrix:news.list) — это готовая связка контроллер + модель + кеширование. Подключаешь в шаблон, настраиваешь через параметры $arParams, кастомизируешь вывод в template.php. Бизнес-логика — в result_modifier.php или в кастомном модуле local/modules/. Шаблон — в local/templates/. Не в ядре, никогда в ядре.

Производительность: что закладывается на старте

Оптимизировать после запуска можно. Но дорого. Вот что закладывается в архитектуру до первого коммита:

Кеширование — три уровня. Управляемый кеш компонентов ($arParams['CACHE_TIME']), общий кеш через memcached или Redis, композитный сайт через модуль composite. Композит отдаёт HTML без инициализации ядра — время ответа падает с 200ms до 15-30ms. Но есть ограничения: не работает для авторизованных пользователей с персональным контентом без дополнительной настройки.

Статика — CDN для /upload/, /bitrix/js/, /bitrix/css/. WebP через CFile::ResizeImageGet() с конвертацией. Lazy loading для изображений ниже fold. Один только вынос статики на CDN снимает 40-60% нагрузки с веб-сервера.

База данных — составные индексы на часто фильтруемые свойства. EXPLAIN на каждый тяжёлый запрос до запуска. Если в каталоге больше 50К товаров — фасетные индексы обязательно: Bitrix\Catalog\Model\SmartFilter пересчитывает их по крону, фильтрация из 3 секунд превращается в 50ms.

PHP — OPcache с JIT на PHP 8.1+, realpath_cache_size=4096K для Битрикса (много файлов — стандартные 16K не хватает). Проверка через панель «Производительность» → «PHP» — там видно, попадает ли всё в OPcache.

Как устроен типичный проект

Шаблон сайта живёт в local/templates/main/. Компоненты подключаются через $APPLICATION->IncludeComponent(). Кастомные шаблоны компонентов — в local/templates/main/components/bitrix/. Не модифицируем штатные шаблоны — потеряются при обновлении.

Модульная структура кода:

• local/modules/project.core/ — бизнес-логика, хелперы, сервисные классы
• local/components/project/ — кастомные компоненты
• local/php_interface/init.php — обработчики событий, но минимально: регистрация модуля и автозагрузчик, остальное — в модуле

Деплой — Git + миграции через sprint.migration. Никакого FTP. Структура инфоблоков, highload-блоков, почтовых шаблонов — всё в миграциях, воспроизводимо на любом окружении.

Этапы

1. Аналитика и проектирование (1-2 недели) — функциональные требования, структура данных, прототипы страниц в Figma. На выходе — спецификация с описанием инфоблоков, компонентов, интеграций
2. Дизайн (1-3 недели) — UI/UX, адаптивные макеты, дизайн-система компонентов
3. Разработка (3-8 недель) — frontend, backend, интеграции. Двухнедельные спринты с демонстрацией на staging
4. Тестирование (1-2 недели) — функциональное, кроссбраузерное, нагрузочное. Чек-лист PageSpeed, Lighthouse, WebPageTest
5. Запуск и стабилизация (3-5 дней) — деплой, мониторинг, устранение проблем первых дней

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

Частые ошибки, которые мы видим на аудитах

• Бизнес-логика в template.php — расчёт скидок, проверка прав, форматирование цен прямо в шаблоне компонента. Невозможно тестировать, невозможно переиспользовать. Выносим в result_modifier.php или в сервисный класс модуля
• Прямые SQL-запросы через $DB->Query() вместо D7 ORM — теряется кеширование, типобезопасность и защита от инъекций
• Один гигантский init.php на 2000 строк — обработчики событий, хелперы, классы — всё в одном файле. Работает, пока не нужно отладить конкретный обработчик. Переносим в модуль с автозагрузкой
• Кеш без тегов — компонент кеширует на час, но данные обновились через 5 минут. Тегированный кеш через $this->SetResultCacheKeys() и CIBlock::clearIblockTagCache() решает проблему
• Обновление ядра без staging — обновили на проде, модуль catalog изменил логику расчёта скидок, корзина сломалась. Всегда сначала staging, потом прод