Коли ми беремося за проєкт на Бітріксі, перше питання — не "який шаблон", а "як спроєктувати структуру даних так, щоб через рік не переписувати фільтри"?
Один невдалий інфоблок з 30 властивостями — і b_iblock_element_property розростається до мільйонів рядків. CIBlockElement::GetList виконується 4 секунди, а фасетний індекс не рятує, тому що властивості-прив'язки не потрапили до b_catalog_sm_*. Переробити на продакшені — переписувати шаблони, фільтри, SEO-правила. Дешевше спроєктувати один раз. Наш досвід показує: правильна архітектура економить до 40% бюджету на підтримку. Типові наслідки неправильної архітектури — зростання часу завантаження сторінок, падіння конверсії та перевитрата бюджету на доробки.
Чому вибір типу зберігання визначає продуктивність?
Це не абстрактне питання. Від нього залежить, які компоненти працюватимуть "з коробки", а які доведеться писати з нуля. Помилка на етапі проектування може коштувати місяців переписування коду.
Інфоблоки зберігають властивості в EAV-таблиці b_iblock_element_property. Для 5 000 товарів з 10 властивостями — 50 000 рядків, MySQL справляється. Для 80 000 товарів з 25 властивостями — 2 000 000 рядків, JOIN-и при фільтрації дають секунди. Зате інфоблоки дають SEO-обв'язку, візуальний редактор, компоненти каталогу.
Highload-блоки — плоска таблиця, колонка на властивість. Індекси ефективні, фільтрація 200 000 записів за 30-80 мс. Немає наслідування властивостей розділів, немає штатного SEO-модуля. Ідеально для довідників (міста, бренди).
D7 ORM (Bitrix\Main\ORM\Data\DataManager) — для сутностей, які не вписуються в інфоблоки або HL-блоки. Заявки зі зв'язками, кастомні логи, агрегації. Повний контроль, але адмінка малюється вручну.
| Критерій | Інфоблоки | Highload-блоки | D7 ORM |
|---|---|---|---|
| Швидкість фільтрації 100К+ товарів | 1-3 с (з фасет. індексом 50-200 мс) | 30-80 мс | Залежить від запиту |
| Штатні компоненти каталогу | Так | Ні | Ні |
| SEO-модуль | Так | Ні | Ні |
| Довільні зв'язки | Обмежені | По полю | Повноцінні |
Як Бітрікс порівнюється з WordPress та Laravel?
WordPress — теж EAV через wp_postmeta, але без штатного e-commerce рівня. WooCommerce — плагін. Бітрікс дає модуль catalog з торговими пропозиціями, типами цін, складським обліком, обміном з 1С через CommerceML. Для компаній, які живуть у 1С:Підприємство, це вирішальний аргумент.
Laravel — фреймворк, не CMS. Свобода архітектури, але каталог, корзина, права доступу, обмін з 1С пишуться з нуля. На проєкті з бюджетом 4-6 місяців і командою з 3 осіб Laravel виправданий. Для корпоративного сайту, який потрібен через 2 місяці, Бітрікс швидше. Не краще — швидше при типових задачах.
Принципова відмінність — компонентний підхід. bitrix:catalog.section — готова зв'язка контролер + модель + кешування. Підключається в шаблон, налаштовується через $arParams, кастомізується в template.php. Бізнес-логіка — в result_modifier.php або в кастомному модулі local/modules/. Шаблон — в local/templates/. Не в ядрі, ніколи в ядрі.
Як ми забезпечуємо продуктивність до першого коміту?
Оптимізувати після запуску дорого. Ось що закладаємо в архітектуру:
Кешування — три рівні: керований кеш компонентів, загальний кеш (memcached/Redis), композитний сайт. Композит віддає HTML без ініціалізації ядра — час відповіді падає з 200 мс до 15-30 мс.
Статика — CDN для /upload/, /bitrix/js/, /bitrix/css/. WebP через CFile::ResizeImageGet(). Lazy loading. Винос статики на CDN знімає 40-60% навантаження з веб-сервера.
База даних — складені індекси на часто фільтровані властивості. EXPLAIN на кожен важкий запит. Для каталогів понад 50 000 товарів — фасетні індекси (Bitrix\Catalog\Model\SmartFilter), фільтрація з 3 секунд перетворюється на 50 мс.
PHP — OPcache з JIT на PHP 8.1+, realpath_cache_size=4096K. Перевірка через панель "Продуктивність" → "PHP".
Кейс: прискорення каталогу в 6 разів
Для клієнта з каталогом 120 000 товарів і 40 властивостями ми перевели фільтрацію з інфоблоків на Highload-блоки з фасетними індексами. Час завантаження сторінки каталогу впав з 4.2 с до 0.7 с. Додатково налаштували композитний кеш для неавторизованих користувачів — перший байт став 25 мс. Економія на підтримці склала до 30% річного бюджету.
Докладніше про композитний режим читайте в офіційній документації.
Що входить в роботу
- Аналіз вимог і проектування архітектури даних
- Розробка дизайну та адаптивна верстка
- Створення кастомних компонентів і модулів
- Інтеграція з 1С (CommerceML), платіжними системами, службами доставки
- Налаштування кешування, CDN, композитного режиму
- Тестування (функціональне, навантажувальне, безпека)
- Документація та навчання адміністраторів
- Гарантійна підтримка 12 місяців
Етапи та терміни
- Аналітика та проектування (1-2 тижні) — специфікація інфоблоків, інтеграцій, прототипи
- Дизайн (1-3 тижні) — UI/UX, дизайн-система
- Розробка (3-8 тижнів) — спринти по 2 тижні, демо на staging
- Тестування (1-2 тижні) — PageSpeed, Lighthouse, WebPageTest
- Запуск (3-5 днів) — деплой, моніторинг, стабілізація
| Масштаб проєкту | Терміни |
|---|---|
| Корпоративний сайт, 10-20 сторінок | 6-10 тижнів |
| Каталог з фільтрацією, до 10 000 товарів | 8-14 тижнів |
| Інтернет-магазин з 1С | 12-20 тижнів |
| B2B-портал з кабінетом | 14-24 тижні |
Терміни коригуються після аналізу вимог. Вартість розраховується індивідуально — занадто багато змінних для шаблонних цифр.
Типові помилки в проєктах на Бітрікс
- Бізнес-логіка в
template.php. Розрахунок знижок, перевірка прав — виносимо вresult_modifier.phpабо сервісний клас модуля. - Прямі SQL-запити (
$DB->Query()) замість D7 ORM. Втрачається кешування, типобезпека, ін'єкції. - Один гігантський
init.phpна 2000 рядків. Переносимо в модуль з автозавантаженням. - Кеш без тегів. Використовуємо
SetResultCacheKeys()таCIBlock::clearIblockTagCache(). - Оновлення ядра без staging. Завжди staging, потім продакшен.
Наші інженери мають сертифікацію 1С-Бітрікс та 10+ років комерційного досвіду. Ми гарантуємо якість та дотримання термінів.
Замовте сайт на Бітрікс — отримайте консультацію та оцінку проєкту за 2 дні. Зв'яжіться з нами, щоб обговорити деталі.