Розробка на 1С-Бітрікс: що стоїть за вибором платформи
Ми часто спостерігаємо: найдорожча помилка в Бітрікс-проєкті — неправильно обрана редакція. Клієнт купує «Бізнес» за значні кошти, а через пів року з'ясовується, що для мультирегіонального каталогу з персональними цінами потрібна «Бізнес Ентерпрайз». Різниця не лише у вартості ліцензії — це інша архітектура зберігання даних, інший підхід до кластеризації, інша стеля продуктивності. Міграція між редакціями на живому проєкті з 80 000 товарів і 200 замовленнями на день — це не оновити ліцензію, а повноцінний інженерний проєкт на 3–6 тижнів. Економія при правильному виборі на старті може становити істотну суму лише на ліцензіях та витратах на міграцію.
Чому вибір редакції Бітрікса — ключове архітектурне рішення?
Інфоблоки — основа Бітрікса для зберігання контенту — мають конструктивне обмеження. Кожна властивість елемента — це запис у b_iblock_element_property (EAV-модель), і при фільтрації каталогу 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 днів |
Замовте аудит вашого проєкту — ми визначимо редакцію, архітектуру та бюджет, а ви отримаєте прозорий план робіт.