Битрикс медленно работает: причины и как ускорить сайт

Если Битрикс медленно работает, первым делом обычно грешат на хостинг - но по опыту процентов 60 обращений ко мне это не про сервер вообще, а про то, как настроен сам проект: активные модули, которые никто не отключил, отсутствие композитного кеша, тяжёлые обработчики событий и десяток агентов, которые крутятся каждую минуту. За последние пару лет я разбирал такие сайты у клиентов из ритейла и услуг - где-то хватало часа на диагностику и включение кеша, где-то приходилось переписывать кастомные компоненты, которые дёргали базу по 200+ раз на странице. Ниже - конкретные причины торможения 1С-Битрикс и что с этим делать, без советов уровня «просто купите хостинг подороже».

Почему Битрикс тормозит: где искать причину

Причины делятся на четыре группы, и на глаз их не различить - нужны цифры. Смотрю обычно в таком порядке:

• Сервер и окружение - версия PHP, настройки MySQL, объём памяти, диска, нагрузка от соседей на shared-хостинге.
• Код проекта - кастомные компоненты, обработчики событий, агенты, запросы к базе без индексов.
• Настройки самого Битрикса - выключенный композитный кеш, не настроенный autoload, лишние активные модули.
• Фронтенд - вес страницы, число запросов, JS и CSS без минификации, картинки в оригинальном разрешении с телефона менеджера.

На практике причины обычно комбинируются: слабый VPS плюс отключённый кеш дают TTFB в 2-3 секунды там, где нормальный показатель - 200-400 мс. Первый шаг - не менять хостинг и не переписывать код на глаз, а снять профиль: включить встроенный монитор производительности (Настройки → Инструменты разработчика → Монитор производительности) и посмотреть, где реально уходит время - в базе, в PHP или во внешних запросах.

Хостинг и сервер: когда битрикс медленно работает из-за железа

Из десятка проектов, которые я разбирал за последний год, в трёх виноват был именно сервер. Частые находки:

• PHP 7.2-7.4 вместо 8.1+ - на восьмой версии движок Zend получил ощутимый прирост, для типового каталога это минус 20-30% времени выполнения скрипта без единой правки кода.
• Отключённый OPcache или маленький opcache.memory_consumption - на каталоге в 1500+ товаров с десятком инфоблоков 64 МБ не хватает, кеш перезаписывается на лету, и профит от него пропадает.
• MySQL без тюнинга - innodb_buffer_pool_size по умолчанию в 128 МБ на базе весом 2-3 ГБ означает, что диск читается на каждый чих. Поднимаю буфер минимум до 50-70% от объёма базы, если памяти сервера хватает.
• Общий хостинг вместо VPS - на shared-тарифах соседи по серверу забирают CPU в пиковые часы, и тормозить сайт начинает не потому, что что-то сломалось, а потому что кто-то рядом запустил тяжёлый импорт.
• Cron-задачи и агенты, которые не разнесены по времени - если пересчёт цен, экспорт в 1С и рассылка стартуют одной минутой, сервер на несколько секунд проседает целиком, и это видно в логах как случайные лаги.

На VPS с 4 ГБ памяти и 2 ядрами (на рынке такие тарифы у большинства провайдеров стоят от 1500 до 3000 ₽ в месяц) грамотно настроенный Битрикс с композитным кешем спокойно держит каталог на 5000-10000 товаров с посещаемостью 500‑1000 визитов в день. Если на такой конфигурации TTFB выше секунды - дело не в мощности, а в настройках.

Модули, инфоблоки и код: что реально грузит систему

Битрикс из коробки тянет модули, которые в большинстве интернет-магазинов не нужны - форум, блоги, соцсеть, вебформы в старой реализации. Каждый активный модуль добавляет обработчики событий, которые срабатывают на каждый хит, даже если функциональность не используется. Отключаю то, что реально не задействовано, через Настройки → Модули - это не всегда даёт прирост в секундах, но снимает лишнюю нагрузку на автозагрузку классов.

Дальше - кастомные компоненты. Частая история: разработчик до меня выводил список товаров через CIBlockElement::GetList в цикле, дёргая для каждого элемента отдельный запрос за остатками, ценами и картинками. На странице каталога с 40 товарами это 120+ запросов к базе вместо одного JOIN. Профилировщик такие места находит сразу - по количеству запросов на компонент.

Похожая история с интеграциями: расчёт доставки СДЭК или Почты России, если он дёргается синхронно при каждой отрисовке корзины, а не кешируется хотя бы на 15-20 минут, добавляет 300-800 мс к каждому запросу - внешний сервис просто не отвечает мгновенно. Ставлю кеш на такие вызовы или переношу расчёт на AJAX после отрисовки страницы, чтобы пользователь не ждал ответа сервиса доставки ради того, чтобы увидеть карточку товара.

Отдельно смотрю на агенты (агентские функции Битрикса) - задачи, которые крутятся по расписанию внутри хитов пользователей. Если агент экспорта в 1С запускается каждую минуту и не укладывается в это время, задачи начинают наслаиваться друг на друга, и каждый следующий хит тянет за собой хвост из невыполненных агентов. Решение простое - вынести тяжёлые агенты на реальный cron через bitrix_cron_events.php вместо агента внутри хита.

Композитный кеш и другие встроенные механизмы ускорения

Композитный кеш - это первое, что я проверяю. Он кеширует HTML целиком, кроме персональных блоков (корзина, авторизация), и обычно даёт кратный прирост на статичных страницах вроде каталога и карточки товара. Включается в Настройках → Настройки продукта → Автокеширование, но у многих сайтов он выключен «на всякий случай» ещё с этапа разработки и так и остался выключенным в проде.

Дальше - HTML-кеш компонентов (кеш второго уровня) и управляемый кеш для тяжёлых выборок из базы. Для интернет-магазина с фильтрами и большим каталогом управляемый кеш экономит секунды на страницах с фасетным фильтром - без него каждый клик по фильтру пересчитывает выборку заново.

Из системного: Redis вместо файлового кеша ускоряет чтение кеша на многопроцессном хостинге, где несколько PHP-воркеров конкурируют за один и тот же файл.

Что я обычно включаю первым и какой эффект это даёт на типовом каталожном сайте - по моим замерам на нескольких проектах, не гарантия для конкретно вашего сайта:

Важная деталь: композитный кеш ломается, если в шаблоне где-то выводится динамика без пометки как некешируемая область - счётчик товаров в корзине, персональные рекомендации. Такие блоки нужно явно оборачивать в некешируемые зоны, иначе или кеш ломается целиком, или пользователи видят чужие данные - это уже вопрос безопасности, а не только скорости.

Фронтенд: почему сайт долго грузится в браузере

Бэкенд можно вылизать до идеала, но если картинка карточки товара весит 3-4 МБ, потому что менеджер загрузил её прямо с телефона без сжатия, пользователь всё равно будет ждать. Частые проблемы на фронтенде:

• Изображения без WebP/AVIF и без ресайза под реальные размеры блоков - Битрикс отдаёт оригинал, если не настроен ресайзер (CFile::ResizeImageGet или готовый модуль).
• JS и CSS россыпью, без объединения и минификации - в Настройках продукта есть штатная опция объединения файлов, но она часто выключена, потому что когда-то ломала вёрстку одного из компонентов, и с тех пор её никто не включал обратно.
• Отсутствие lazy-load для изображений ниже первого экрана - на длинной странице каталога грузятся все 40 картинок сразу, хотя видно 8.
• Синхронные сторонние скрипты в head - счётчики аналитики, виджеты чатов, встроенные iframe от лендингов на Tilda, подключённые прямо в шаблон Битрикса, блокируют рендеринг на секунду и больше.
• Отсутствие CDN для статики - если сервер физически в Москве, а часть аудитории из регионов, каждый файл стилей и картинка едут через один канал.

После такой чистки на одном из проектов PageSpeed Insights по мобильному вырос с 38 до 71, а визуальная загрузка (Largest Contentful Paint) сократилась с 4.2 до 1.8 секунды - без единой правки бэкенда, только фронтенд.

Чтобы не откатиться обратно после следующего релиза - новый баннер на 5 МБ или очередной виджет в head возвращают всё как было - ставлю регулярный замер веса и скорости ключевых страниц; в библиотеке готовых скриптов у меня есть шаблон именно под такой мониторинг на Python, который раз в день гоняет ключевые страницы и присылает отчёт, если метрики просели.

Чек-лист: что и в каком порядке ускорять

Порядок, который на практике даёт максимальный эффект при минимальном риске:

1. Включить композитный кеш и проверить, что персональные блоки помечены как некешируемые.
2. Обновить PHP и включить OPcache с адекватным объёмом памяти.
3. Настроить MySQL - buffer pool, slow query log, и по логу найти запросы без индексов.
4. Разнести cron и агенты по времени, тяжёлые задачи перенести на настоящий cron.
5. Прогнать профилировщик по ключевым страницам и переписать компоненты с N+1 запросами.
6. Настроить ресайз и сжатие изображений, включить объединение JS/CSS, добавить lazy-load.
7. Подключить CDN для статики, если аудитория географически распределена.

Каждый шаг проверяю по TTFB и PageSpeed до и после - без замеров легко потратить день на правки, которые дают 20 мс прироста, вместо того чтобы найти один запрос, который тянет 800 мс. Обычно на диагностику и первые исправления (кеш, opcache, агенты) уходит от нескольких часов до дня, переписывание тяжёлых компонентов и интеграций - дольше, зависит от объёма кастомного кода.

Частые вопросы

Сколько стоит ускорить Битрикс на практике?

Диагностика обычно укладывается в консультацию - от 3 000 ₽, дальше объём работ зависит от находок: включить кеш и поправить настройки сервера можно за несколько часов, переписать тяжёлые компоненты или интеграции с доставкой и 1С - дольше. Если после исправлений нужен постоянный контроль, беру такие проекты на техподдержку - от 15 000 ₽ в месяц, туда входит и мониторинг скорости после каждого релиза.

Поможет ли просто переезд на VPS помощнее?

Часто помогает временно. Если каталог небольшой, а кеш и код в порядке, апгрейд сервера снимает проблему целиком. Но если тормозит из-за отключённого композитного кеша или запросов без индексов, более мощный сервер маскирует проблему на несколько месяцев - каталог подрастёт на пару тысяч товаров, и сайт снова начнёт тормозить, только уже на более дорогом тарифе. Сначала профилирую, потом решаю, нужен ли апгрейд железа вообще.

Нужно ли обновлять Битрикс до последней версии ради скорости?

Сама по себе версия ядра не главный фактор - важнее актуальный PHP и включённые механизмы кеширования, которые есть и в более старых редакциях. Апдейт полезен для безопасности и доступа к новым возможностям платформы, но без настройки кеша и чистки кода прирост скорости от одного обновления ядра будет минимальным.

Как понять, что именно тормозит - сервер или код?

Сравниваю TTFB на закешированной странице и на странице с отключённым кешем - если разница в разы, дело в коде и настройках кеша, а не в железе. Дальше смотрю slow query log MySQL на запросы без индексов и встроенный монитор производительности Битрикса, который показывает время по компонентам. Если время съедает конкретный компонент с сотней запросов на страницу - это код, а не сервер.