Розробка сайту на 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, потім прод