Почему сайт на Битриксе стал медленно работать и как это исправить

«Раньше всё летало, а сейчас страница грузится по 8 секунд» — одна из самых частых жалоб на сайты, которые работают несколько лет. Битрикс — не «тормозная CMS», как иногда говорят: при правильной настройке он отлично выдерживает большие нагрузки. Просто за годы эксплуатации в нём накапливаются десятки мелких проблем, каждая из которых добавляет 100–300 мс к загрузке. В сумме это превращается в проблему. Разберём, как её диагностировать и исправить.

Сначала — измерьте

Прежде чем что-то оптимизировать, нужно знать точку отсчёта. Прогоните сайт через инструменты:

• PageSpeed Insights — общие метрики, рекомендации Google, Core Web Vitals.
• WebPageTest — детальная диаграмма загрузки, можно тестировать из разных регионов.
• GTmetrix — удобная история замеров и сравнение версий.
• Встроенный Битрикс «Анализ производительности» в админке — покажет узкие места внутри ядра.

Цель — понять, где теряется время: на сервере (TTFB), при загрузке статики, или в JavaScript на клиенте. Дальше — действовать прицельно.

Причина 1: не включён композитный кэш

Composite — родная технология Битрикса для кэширования страниц целиком. Включается за 5 минут в админке, а ускоряет TTFB в 5–20 раз. Парадокс — на половине сайтов он либо не включён, либо отключился после какого-то обновления, и никто не заметил.

Что делать: проверить в «Настройки → Производительность → Композитный сайт», что он включён. Настроить условия включения (для авторизованных, для корзины и т.д.). После запуска проверить, что страницы отдаются с заголовком `X-Bitrix-Composite: Cache (200)`.

Причина 2: устаревшая версия PHP

Сайт работает на PHP 7.4 или, что ещё хуже, на PHP 7.0. PHP 8.2 даёт прирост производительности 25–40% «бесплатно» — без изменения кода. Но обновление PHP — это шаг, который страшно делать на работающем магазине.

Что делать: в тестовом окружении обновить PHP до 8.2 (Битрикс с версии 22.0 поддерживает эту версию официально). Проверить совместимость кастомных модулей. Запустить нагрузочное тестирование. Если всё ок — мигрировать продакшн в окно низкой нагрузки.

Причина 3: нет индексов в БД

Каталог разросся с 500 до 50 000 товаров, а индексы в инфоблоках остались дефолтные. Запросы на фильтрацию каталога перестали попадать в индексы и начали сканировать всю таблицу. Один такой медленный запрос может тянуть всю страницу на 3–5 секунд.

Что делать: включить slow log в MySQL и проанализировать самые медленные запросы. Создать индексы на свойства, по которым идёт фильтрация (`b_iblock_element_property` и таблицы свойств). Для часто используемых сортировок — составные индексы. Для крупных каталогов — отдельные таблицы свойств (highload-блоки).

Причина 4: неправильное кэширование компонентов

Компоненты Битрикса умеют кэшироваться, но «по умолчанию» — обычно с TTL 36000000 (~417 дней). При этом если разработчики передают в `arParams` динамические данные (текущее время, ID пользователя), каждый запрос создаёт новый кэш-файл. Папка `bitrix/cache` разрастается до сотен гигабайт, и кэш перестаёт быть кэшем.

Что делать: проверить размер `bitrix/cache` (если больше 5–10 ГБ — проблема). Найти компоненты, у которых параметры включают `time()`, `$_SERVER`, `RANDOM()`. Переписать так, чтобы кэш зависел только от стабильных параметров. Включить тегированный кэш и настроить инвалидацию по событиям.

Причина 5: нет CDN для статики

Картинки, CSS, JS отдаются с того же сервера, что и сайт. На каждой странице 50–100 запросов, каждый с TTFB 100–200 мс — итого 5–10 секунд на одну только статику для пользователя из другого региона.

Что делать: подключить CDN (Selectel CDN, Cloudflare, Yandex CDN). Битрикс с версии 20+ поддерживает встроенную интеграцию с Selectel CDN. Дополнительно — оптимизировать изображения в формат WebP, ленивая загрузка (`loading="lazy"`), современные форматы видео.

Причина 6: тяжёлый JavaScript

Шаблон собирает в одну страницу jQuery, jQuery UI, Slick, Owl Carousel, Swiper, Fancybox, два разных счётчика аналитики, чат на сайте, виджет от партнёров. Суммарно — 2–3 мегабайта JavaScript, который полностью блокирует рендеринг на мобильных.

Что делать: провести аудит используемых библиотек. Удалить дубли (часто слайдеров на сайте 2–3 разных). Перенести аналитику в `defer`, чаты — в `async`, ненужное на главной — на `lazy load` после первого взаимодействия. Минифицировать и объединять — Битрикс это делает встроенно при правильной настройке.

Причина 7: слишком много модулей

За годы поставили 20+ модулей с маркетплейса: «улучшенный поиск», «расширенная корзина», «продвинутая SEO-оптимизация» и так далее. Половина из них уже не используется, но висят в системе и подключают свои файлы на каждой странице.

Что делать: пройтись по списку модулей в админке и отключить всё, что не используется. Перед удалением сделать бэкап. Особое внимание — модулям, которые перехватывают события (`OnPageStart`, `OnEpilog`) — они влияют на каждый запрос.

Причина 8: внешние API без таймаутов

В шаблоне или в компоненте делается синхронный запрос к внешнему API — например, к API курьерской службы для расчёта доставки или к социальной сети для виджета. Если внешний сервис тормозит, ваш сайт тормозит вместе с ним. Без таймаута — может висеть 30+ секунд.

Что делать: ставить таймаут на все внешние HTTP-запросы (3–5 секунд максимум). Кэшировать результаты с подходящим TTL. Тяжёлые операции (расчёт доставки) — вынести в AJAX, чтобы они не блокировали загрузку основной страницы.

Причина 9: фрагментация и мусор в БД

Таблицы кэша, журналов, событий разрослись до десятков гигабайт. Удалять «вручную» страшно. Запросы становятся медленными даже к самым простым таблицам.

Что делать: настроить регулярную очистку устаревших данных через cron — журнал событий старше 30 дней, временные файлы, кэш агентов. Раз в квартал — `OPTIMIZE TABLE` на больших таблицах. Если БД совсем разрослась — рассмотреть переезд на отдельный сервер БД.

Причина 10: один сервер на всё

Сайт, БД, файловое хранилище, почта — всё на одной виртуалке за 3 тысячи в месяц. На пиках сайт упирается в CPU или память, и любое действие тормозит.

Что делать: для коммерческих сайтов — выделять отдельный сервер БД от веб-сервера, файлы хранить на S3-совместимом хранилище. Для крупных проектов — балансировщик и несколько веб-серверов. Битрикс с редакции «Энтерпрайз» поддерживает кластеризацию из коробки.

Пошаговый план оптимизации

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

• Шаг 1. Замерьте текущую скорость (PageSpeed, GTmetrix). Зафиксируйте цифры.
• Шаг 2. Включите композитный кэш — это 30–60% выигрыша «бесплатно».
• Шаг 3. Подключите CDN для статики — ещё 20–40% по времени загрузки.
• Шаг 4. Обновите PHP до актуальной версии — 25–40% к производительности кода.
• Шаг 5. Оптимизируйте изображения (WebP, lazy loading, правильные размеры).
• Шаг 6. Сделайте аудит JS — уберите дубли и тяжёлые библиотеки.
• Шаг 7. Проанализируйте slow log БД и добавьте недостающие индексы.
• Шаг 8. Настройте регулярную очистку и оптимизацию БД.
• Шаг 9. Замерьте снова — обычно прирост в 2–4 раза.

Когда оптимизация не поможет

Иногда проблема не в настройках, а в том, что шаблон или код «противоречат» правилам Битрикса. Например, выводятся товары через прямые SQL-запросы вместо стандартных компонентов и модели данных. В этом случае никакой кэш не поможет — нужно переписывать. Если после всех вышеперечисленных шагов сайт всё ещё медленный, пора смотреть в код шаблона.

Что в итоге

Битрикс — производительная CMS, если её правильно настроить и поддерживать. Большинство «тормозов» — это накопленный за годы технический долг, который полностью устраняется без переписывания сайта. План работ на 2–4 недели обычно даёт ускорение в 2–5 раз и заметно улучшает поведенческие факторы для SEO. Главное — действовать системно, измерять до и после каждого шага и не пытаться оптимизировать всё сразу.

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