Оптимизация производительности сайтов на 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-50x, плюс работает в кластере - Кэш компонентов → 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 дополнительной выручки ежемесячно.







