Как мы ускорили интернет-магазин на 1С-Битрикс с 8 до 1.2 секунды

Исходная ситуация: магазин тормозил до неприличия

К нам обратился клиент — владелец интернет-магазина строительных материалов на 1С-Битрикс. Каталог содержал около 480 000 товарных позиций, настроен фильтр по 40+ параметрам. Среднее время загрузки страницы каталога составляло 7.8–9.2 секунды.

Поисковики уже начали проседать — позиции в Яндексе падали, конверсия снизилась на 34% за полгода. Клиент обратился к нам с одним запросом: «Сделайте быстро».

«У нас не маленький сайт-визитка — это живой магазин с 2000 заказов в месяц. Каждая секунда ожидания — это уходящий покупатель.»

Диагностика: что именно тормозило

Прежде чем что-то трогать, мы провели полную диагностику. Инструменты: Xdebug профайлер, Bitrix Performance Monitor, EXPLAIN ANALYZE для SQL-запросов и New Relic APM.

Вот что нашли:

• SQL-запросы к таблице b_iblock_element_prop_s* — каждая загрузка страницы генерировала 180–220 отдельных запросов к свойствам товаров. Суммарное время — 4.1 сек.
• Полнотекстовый поиск через LIKE — стандартный поиск Битрикса делал LIKE по нескольким миллионам строк без индексов.
• Отсутствие кэша на уровне приложения — каждый запрос к фильтру пересчитывался с нуля.
• Некомпрессированные изображения — средний вес страницы категории составлял 11 МБ из-за PNG-изображений без оптимизации.
• PHP 7.2 — устаревшая версия без JIT-компилятора.

Что мы сделали: шаг за шагом

Шаг 1. Переход на PHP 8.2 + OPcache

Первое, что сделали — обновили окружение. PHP 8.2 с правильно настроенным OPcache дал прирост около 15–20% без каких-либо изменений в коде.

Конфигурация OPcache в php.ini:

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.enable_cli=1

Шаг 2. Redis для кэширования Битрикс

Заменили файловый кэш Битрикса на Redis. Это кардинально изменило ситуацию с повторными запросами.

В файле /bitrix/.settings.php прописали:

'cache' => [
    'value' => [
        'type' => 'redis',
        'redis' => [
            'host' => '127.0.0.1',
            'port' => 6379,
            'serializer' => 'php',
        ],
    ],
],

Время хита кэша снизилось с 40 мс (файловый кэш) до 0.8 мс (Redis). На страницах с высокой повторяемостью запросов это дало ощутимый прирост.

Шаг 3. Elasticsearch вместо стандартного поиска

Это был самый трудоёмкий, но и самый эффективный шаг. Стандартный модуль поиска Битрикса использует полнотекстовый индекс MySQL, который на 480k товаров работает крайне медленно.

Мы подняли Elasticsearch 8.x, написали кастомный индексер, который:

• Индексирует товары по мере их изменения в Битриксе (через обработчики событий)
• Хранит в индексе все нужные фильтровые свойства
• Возвращает результаты с учётом склонений, опечаток и синонимов

Время ответа на поисковый запрос: с 3.4 сек → 90 мс.

Шаг 4. Оптимизация SQL и структуры инфоблока

Проанализировали все медленные запросы через slow query log. Добавили составные индексы на таблицы свойств:

ALTER TABLE b_iblock_element_prop_s4
ADD INDEX idx_iblock_element (IBLOCK_ID, IBLOCK_ELEMENT_ID);

ALTER TABLE b_iblock_element_prop_m4  
ADD INDEX idx_iblock_prop_element (IBLOCK_ID, IBLOCK_PROPERTY_ID, IBLOCK_ELEMENT_ID);

Также перевели «тяжёлые» фильтровые свойства с множественного хранения (таблица m*) на одиночное (таблица s*) там, где это было возможно. Количество SQL-запросов на загрузку страницы снизилось с 220 до 34.

Шаг 5. Оптимизация изображений

Написали консольный скрипт на PHP, который прошёлся по всем 480k товаров и:

• Конвертировал PNG → WebP с fallback на JPEG
• Сжал изображения без потери качества (mozjpeg + cwebp)
• Добавил loading="lazy" для картинок ниже первого экрана

Средний вес страницы каталога: с 11 МБ → 1.8 МБ.

Шаг 6. Nginx кэширование на уровне сервера

Для страниц каталога без фильтров добавили кэширование на уровне Nginx с TTL 5 минут. Анонимные пользователи (основная масса трафика) получают статически закэшированную страницу без обращения к PHP.

Результаты

Через 3 месяца после оптимизации органический трафик из Яндекса вырос на 67% — сайт начал подниматься по позициям, которые потерял из-за медленной загрузки.

Выводы и что важно понимать

Ускорение большого Битрикс-магазина — это не одна «волшебная кнопка», а системная работа на нескольких уровнях одновременно: окружение, кэш, поиск, база данных, ресурсы.

Самые распространённые ошибки, которые мы видим у клиентов:

• Хранение тысяч свойств в множественном типе без необходимости
• Отсутствие Redis/Memcache — всё хранится в файловом кэше
• Стандартный поиск Битрикса на каталоге 100k+ товаров
• Отсутствие мониторинга медленных запросов

Производительность — это не разовая задача. Это процесс, который нужно поддерживать по мере роста каталога и трафика.

Если ваш магазин тормозит — мы готовы провести бесплатный технический аудит и предложить конкретный план оптимизации.