Оптимізація продуктивності сайтів на 1С-Бітрікс
b_iblock_element_property — таблиця, через яку гальмує 80% проєктів на Бітрікс. EAV-структура: один рядок на кожне значення кожної властивості кожного елемента. Каталог у 50 000 товарів з 30 властивостями — півтора мільйона рядків. Розумний фільтр робить JOIN цієї таблиці з b_iblock_element за п'ятьма властивостями — і MySQL йде у full table scan на 3-5 секунд. Оптимізація Бітрікс починається з цієї таблиці й розходиться на всю інфраструктуру.
Серверна оптимізація
Nginx. Не просто «увімкнули gzip». Конкретно:
-
gzip_comp_level 4-5— вище безглуздо, CPU з'їдає більше, ніж економить трафік -
brotli onзbrotli_static on— для попередньо стиснених файлів - HTTP/2 з
http2_max_concurrent_streams 128 -
fastcgi_cacheдля PHP-відповідей — кешування на рівні Nginx, минаючи PHP-FPM взагалі -
worker_processes auto,worker_connectionsпід реальну кількість одночасних з'єднань
PHP-FPM. Вибір між pm = dynamic та pm = static — не академічний:
- Static: фіксована кількість воркерів, без overhead на форк. Для виділених серверів з передбачуваним навантаженням
- Dynamic: економить RAM при низькому трафіку.
pm.max_childrenрозраховуємо як(доступна RAM - RAM для MySQL/Redis) / середня витрата на процес - OPcache:
opcache.memory_consumption=256,opcache.max_accelerated_files=20000,opcache.validate_timestamps=0на продакшені (перезавантаження PHP-FPM при деплої)
MySQL/MariaDB. Майже завжди головне вузьке місце:
-
slow_query_logз порогом 0.5 сек. Розбираємо кожен запит черезEXPLAIN -
innodb_buffer_pool_size= 70-80% доступної RAM на виділеному сервері -
query_cache_type = 0на MySQL 8.x (query cache видалено) або MariaDB зquery_cache_sizeпід профіль навантаження - Складені індекси для фасетного пошуку:
(IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE)наb_iblock_element_property -
OPTIMIZE TABLE b_iblock_element_propertyпісля масових операцій
Кешування: три рівні
Керований кеш компонентів. TTL налаштовуємо для кожного компонента окремо. Каталог — 3600 сек, стрічка новин — 300 сек, банери — 86400. Однаковий TTL скрізь — гарантія або застарілих даних, або марного кешу.
Композитний кеш. Технологія «Композитний сайт» (bitrix:composite). Nginx віддає готовий HTML з файлу, PHP не запускається. Динамічні зони (кошик, авторизація, регіональний контент) підвантажуються AJAX-запитом через CBitrixComponent::setFrameMode(true). TTFB < 50 мс. Але: не всі компоненти сумісні, $APPLICATION->ShowPanel() та прямий вивід через echo ламають композит. Перевіряємо кожну сторінку через панель «Продуктивність → Композитний сайт».
Memcached / Redis. Переносимо кеш з файлової системи:
- Сесії → Redis (
session.save_handler = redis). Швидше за файлове зберігання у 10-50 разів, плюс працює у кластері - Кеш компонентів → Memcached через налаштування у
.settings.php:'cache' => ['type' => 'memcache'] - Кеш ORM-запитів — щоб однакові
GetList()не навантажували MySQL на кожному хіті
Фронтенд
Зображення — 60-80% ваги сторінки:
- WebP через
CFile::ResizeImageGet()зBX_RESIZE_IMAGE_PROPORTIONAL+ конвертація -
srcset+sizes— не вантажимо 3000px картинку у блок 400px -
loading="lazy"для всього нижче першого екрану - AVIF для браузерів з підтримкою — ще 20-30% економії vs WebP
CSS/JS:
- Вбудований модуль Бітрікс: об'єднання та мініфікація через «Налаштування → Оптимізація CSS/JS»
- PurgeCSS / UnCSS — на типовому Бітрікс-проєкті 60-70% CSS не використовуються (підтягуються стилі всіх підключених компонентів)
-
defer/asyncдля некритичного JS - Critical CSS інлайном у
<head>для миттєвого FCP
Шрифти:
-
<link rel="preload" as="font" crossorigin>для основного шрифту -
font-display: swap— текст видно одразу, шрифт довантажується - Subsetting через
pyftsubset— вирізаємо кирилицю + латиницю, решта не потрібна. Файл зменшується у 3-5 разів
CDN
- Cloudflare, BunnyCDN, AWS CloudFront або українські/російські (Selectel CDN, VK Cloud CDN)
- Статика (CSS, JS, зображення, шрифти) — через CDN
- Правила кешування:
Cache-Control: public, max-age=31536000, immutableдля файлів з хешем у назві -
imgproxyабо Cloudflare Polish — оптимізація зображень на льоту, без навантаження на origin
Навантажувальне тестування
Не синтетичні бенчмарки, а реальні сценарії:
- k6 / wrk — імітація маршрутів: каталог → фільтрація → картка → кошик → оформлення
- Метрики: RPS, час відповіді (p50, p95, p99), відсоток помилок
-
Xdebug (callgrind) або Blackfire — профілювання PHP, пошук конкретних вузьких місць. Бачимо, що
CIBlockElement::GetList()з п'ятьмаPROPERTY_*фільтрами займає 2 сек — оптимізуємо саме цей виклик
Оптимізація БД: глибше стандартних налаштувань
Індекси. Складені індекси для фасетного пошуку. Покривні індекси для частих вибірок — MySQL відповідає з індексу, не звертаючись до даних. Часткові індекси (MariaDB) для фільтрації за ACTIVE = 'Y'. Аудит невикористаних індексів — кожен уповільнює INSERT/UPDATE.
Партиціонування. Для таблиць з мільйонами рядків: b_stat_session, b_search_content_stem, Highload-блоки з історією. Партиціонування за датою — запит «замовлення за місяць» не сканує дані за три роки.
Очищення. У будь-якій базі Бітрікс за рік-два накопичується: застарілий пошуковий індекс у b_search_content, прострочені записи у b_cache_tag, історія b_iblock_element_prop_s* за роки, логи у b_event_log на гігабайти. Налаштовуємо регулярне очищення через агенти.
Результати
| Метрика | До | Після |
|---|---|---|
| TTFB | 800-2000 мс | 50-200 мс |
| Повне завантаження | 4-8 сек | 1.5-2.5 сек |
| PageSpeed (мобільний) | 30-50 | 80-95 |
| Одночасні користувачі | 50-100 | 500-2000+ |
Моніторинг
Без моніторингу через півроку все деградує. Новий модуль, нерозчищені логи, зміна у шаблоні — і швидкість повернулася до початкової.
- web-vitals API — Real User Monitoring від реальних відвідувачів
- Synthetic monitoring — Pingdom, UptimeRobot, регулярні перевірки з різних локацій
- Алерти — TTFB > 500 мс або LCP > 3 сек → сповіщення
Хостинг
| Тип | Для кого | Обмеження |
|---|---|---|
| Shared | Візитки, до 500 відвідувань/день | Немає контролю над PHP-FPM, Redis, Nginx |
| VPS/VDS | Більшість проєктів | До 30K відвідувань/день при правильному налаштуванні |
| Dedicated | Великі магазини | Повний контроль, NVMe, багато RAM |
| Хмара (Yandex Cloud, VK Cloud, AWS) | Нерівномірне навантаження | Автоскейлінг на розпродажах, відмовостійкість |
Вартість
| Тип робіт | Терміни | Вартість |
|---|---|---|
| Базова оптимізація (кеш, зображення, мініфікація) | 2-3 дні | від 25 000 руб. |
| Оптимізація БД (індекси, slow queries, налаштування) | 3-5 днів | від 40 000 руб. |
| Серверна інфраструктура (Nginx, PHP-FPM, Redis) | 2-3 дні | від 30 000 руб. |
| Комплексна (сервер + БД + фронтенд + CDN) | 1-3 тижні | від 80 000 руб. |
| Навантажувальне тестування і профілювання | 2-3 дні | від 20 000 руб. |
| Кластерна архітектура (балансування, реплікація) | 1-2 тижні | від 120 000 руб. |
Скорочення TTFB на 1 секунду дає приблизно +7% до конверсії. Для магазину з оборотом 5 млн/міс — це 350K додаткової виручки щомісяця.