Сайт на Битриксе тормозит: 6 причин и как найти свою

Что вы получите из статьи:

• 6 причин, по которым тормозит именно Битрикс, и симптом каждой, понятный без программиста
• 1 отчёт в Яндекс Метрике, который за 5 минут показывает, где тормозит: на сервере или в браузере
• пороги Google, с которыми сравнивать свой сайт: ответ сервера до 0,8 с, главный блок до 2,5 с
• 7 скриншотов из админки Битрикса, которые стоит попросить у подрядчика

Из практики: применить можно за около часа на самодиагностику, экономит деньги на ускорение вслепую и на переезд на дорогой тариф, когда тормозит код каталога.

Если сайт на Битриксе тормозит, причин шесть типовых, и они зависят от самой платформы: слабый сервер или старый PHP, выключенный кеш компонентов, не работающий композитный сайт, агенты «на хитах», тяжёлые запросы каталога к базе и невключённая оптимизация CSS и JS. Ориентиры дают пороги Google: сервер отвечает за 0,8 секунды или быстрее, главный блок страницы появляется не позже 2,5 секунды. Минимум самого Битрикса сейчас - PHP 8.2 и MySQL 8.0. Круг причин можно сузить самому, без доступа к админке: по отчёту Метрики и по тому, какие именно страницы медленные.

Как выглядит время ответа сайта по дням, можно посмотреть без регистрации: демо-кабинет ARTGK Code на демонстрационных данных.

Почему тормозит именно сайт на Битриксе?

Коротко: сам вендор ещё в 2012 году делил причины медленной работы сайта на три группы: настройки платформы, сервер и качество кода. Из них получается шесть типовых причин. В Битриксе есть кеш, композит и монитор производительности, но каждый из них нужно включить и настроить под ваш сайт.

В блоге компании «1С-Битрикс» (сейчас блог подписан «Битрикс24») на Хабре (статья 2012 года, но логика с тех пор не изменилась) причины скорости разложены на три группы: платформа и её настройки, конфигурация сервера и ПО, качество разработки и интеграции. Наши шесть причин ложатся в эти группы так:

1. Сервер не тянет или окружение устарело (группа «сервер»).
2. Кеширование компонентов выключено (настройки платформы).
3. Композитный сайт не включён или не работает (настройки платформы).
4. Агенты выполняются на хитах (настройки платформы).
5. Тяжёлые запросы к базе у каталога, фильтра и поиска (качество кода).
6. Не включена оптимизация CSS и JS (настройки платформы).

Если сайт совсем не открывается, нужна другая статья: «Сайт не открывается: что делать по шагам». Общие приёмы для любого движка (картинки, сторонние виджеты, телефон вместо компьютера) мы разбирали в статье «Как ускорить загрузку сайта», здесь они не повторяются. Дальше - только то, что устроено по-своему в Битриксе.

Как понять, где тормозит: на сервере или в браузере?

Коротко: откройте в Яндекс Метрике отчёт «Время загрузки страниц» и посмотрите «Ответ сервера». Если он больше 0,8 секунды, ищите причины 1-5. Если он меньше 0,8 секунды, а главный блок страницы (LCP) появляется позже 2,5 секунды, причина 6 и фронтенд, то есть всё, что происходит уже в браузере. Для ответа сервера Google считает хорошим значением 0,8 секунды и меньше, плохим - больше 1,8 секунды.

Путь в Метрике по справке Яндекса: «Отчеты → Мониторинг → Время загрузки страниц». В отчёте несколько этапов загрузки. Нас интересует «Ответ сервера» - Яндекс определяет его как время от отправки запроса до получения браузером ответа с содержимым страницы и уточняет, что на этот показатель влияют скорость генерации ответа веб-сервером, размер страницы и скорость интернет-канала. По умолчанию отчёт показывает квантиль 50%, то есть типичное значение. Переключите на 90%: так видно, сколько ждут посетители в самых медленных 10% открытий.

Пороги из документации Google для времени до первого байта (TTFB): значения 0,8 секунды и меньше считаются хорошими, больше 1,8 секунды - плохими. Для главного блока страницы (LCP) порог другой: 2,5 секунды и меньше, измерять по 75-му перцентилю загрузок. Что такое LCP, INP и CLS, разобрано в статье про Core Web Vitals простыми словами.

Мерить нужно не из-под администратора. Документация Битрикса советует проверять композитный сайт в режиме инкогнито как анонимный пользователь. Группы с доступом к админке не должны входить в группы композита, поэтому у администратора страница собирается без него и может открываться медленнее, чем у посетителей.

Если Метрики нет или разбираться в ней не хочется, время ответа сайта каждые 5 минут видно в разделе «Мониторинг» кабинета ARTGK Code. Подробнее - в отдельном разделе ниже.

Причина 1. Сервер не тянет или PHP устарел?

Коротко: если медленно открываются все страницы, даже «Контакты», первым подозревают сервер. По требованиям 1С-Битрикс минимум - PHP 8.2 и MySQL 8.0: у MySQL 8.0 поддержка уже закончилась, у PHP 8.2 исправления безопасности заканчиваются 31 декабря 2026 года. В админке есть «Проверка системы» и «Панель производительности» со сравнением с эталоном. Просить нужно хостера.

Минимальные технические требования указаны на сайте 1С-Битрикс: PHP 8.2, Apache 2.0 и выше или Nginx, MySQL 8.0 и выше. Вендор даёт и скрипт bitrix_server_test.php, которым можно проверить хостинг на соответствие этим требованиям.

Даты поддержки стоит знать заранее. По данным php.net, у PHP 8.2 активная поддержка закончилась 31 декабря 2024 года, а исправления безопасности выходят до 31 декабря 2026 года. У MySQL 8.0 по данным endoflife.date поддержка закончилась 30 апреля 2026 года. Минимум Битрикса совпадает с версиями, одна из которых уже без поддержки, а у второй исправления безопасности закончатся меньше чем через три месяца. Сама по себе версия не объясняет тормоза, скорость меряет «Панель производительности». Но вопрос хостеру «какой у нас PHP и MySQL» стоит задать до любых других вопросов.

В административной панели есть два встроенных инструмента.

• «Проверка системы» (Настройки > Инструменты > Проверка системы) сверяет параметры сервера с минимальными и рекомендуемыми требованиями продукта. Документация требует: если параметр выделен красным цветом, его нужно исправить.
• «Панель производительности» (Настройки > Производительность > Панель производительности) тестирует проект и сравнивает результат с эталонной системой на виртуальной машине VMBitrix. В примере вендора при производительности 40,32 страница создаётся за 0,0248 секунды, то есть сервер генерирует около 40 пустых страниц с подключённым ядром в секунду. Оценка выводится на закладке «Разработка»; чем выше число, тем быстрее сервер. Замер нужно проводить во время нагрузки, характерной для вашего сайта.

Заодно учтите роботов. Справка Яндекс Вебмастера говорит, что большое число обращений роботов к серверу может увеличивать время ответа сервера. Если сайт тормозит в часы обхода, это повод обсудить скорость обхода с подрядчиком.

Решается причина 1 тарифом или переездом, это разговор с хостером или администратором сервера. Результаты «Проверки системы» и закладки «Конфигурация» панели производительности - то, что стоит показать при разговоре.

Если вы хотите сначала увидеть, как ведёт себя сайт снаружи, бесплатная проверка сайта в кабинете ARTGK Code показывает время ответа каждые 5 минут и оценку скорости по замеру Google PageSpeed. Доступ к сайту не нужен, карта не нужна, вход по коду из письма.

Причина 2. Почему не работает кеш компонентов?

Коротко: если повторное открытие страницы не быстрее первого, вероятно, компоненты (блоки страницы: каталог, меню, корзина) каждый раз собирают данные из базы. В Битриксе есть автокеширование: вендор пишет, что его можно включить одной кнопкой. На магазине с персональными ценами и корзиной включать его без проверки нельзя, иначе посетители увидят устаревшие данные.

Документация Битрикса о кешировании называет четыре технологии: неуправляемое, управляемое, композитный сайт и автокеширование компонентов. Идея у них общая: сайт берёт сохранённые данные вместо того, чтобы каждый раз обращаться к базе.

Включается автокеширование в разделе «Настройки > Настройки продукта > Автокеширование». Пользовательская документация формулирует так: «нетехническому специалисту достаточно включить автокеширование одной кнопкой на административной панели». После этого компоненты с включённым автокешированием создают кеш и работают без запросов к базе данных.

У кеша есть пределы. Не все компоненты поддерживают управляемое кеширование. Для часто обновляемых данных кеш будет постоянно сбрасываться и пересоздаваться, выигрыша может не быть. А при включённой опции «Учитывать права доступа» незарегистрированные пользователи по-прежнему видят неактуальную страницу после кнопки «Обновить кеш страницы». Для магазина это означает простое правило: цены, остатки и корзина проверяются после включения вручную.

Симптом: вы открываете медленную страницу второй раз, и она так же медленна, как первая. Тот же симптом даёт и неработающий композит (причина 3), поэтому различают их по двум скриншотам из админки: «Автокеширование» и «Композитный сайт». Подрядчик должен проверить, включено ли автокеширование и какой режим кеширования стоит у компонентов на медленных страницах. Перед любой правкой настроек нужна свежая резервная копия: как часто её делать, мы разбирали в статье про бэкап сайта.

Причина 3. Включён ли композитный сайт?

Коротко: композит отдаёт посетителю заранее собранную страницу, а меняющиеся части, например корзину, догружает отдельно. Без него, по документации, время загрузки страницы может достигать нескольких секунд. Для работы нужен настроенный nginx (веб-сервер, который отдаёт готовые страницы) и проверка в режиме инкогнито: у администратора композит может не срабатывать.

Композитный сайт - дополнительный уровень кеширования в Bitrix Framework. Без него сервер на каждый запрос проверяет права пользователя, выполняет PHP-скрипты компонентов и формирует HTML. Документация заключает: «В результате время загрузки страницы может достигать нескольких секунд». С композитом готовая страница отдаётся сразу, а динамические куски подгружаются потом.

Включение находится в разделе «Настройки > Настройки продукта > Композитный сайт». Режимов два: «Автокомпозит» подходит для простых сайтов, «Композит» рекомендован для сложных проектов с доработанными компонентами. Перед включением нужно очистить кеш компонентов. Поиск, корзину и оформление заказа вендор советует оставить динамическими.

Три нюанса из документации, которые объясняют, почему «композит включён, а быстрее не стало».

1. Для работы технологии нужно настроить nginx.
2. В списке доменов должны быть указаны все варианты адреса: с www и без.
3. Композит работает только для пользователей из разрешённых групп, а у администратора страница может отдаваться иначе.

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

Причина 4. Что такое агенты и почему они тормозят сайт?

Коротко: агенты - задачи Битрикса, которые запускаются по расписанию. По умолчанию они могут запускаться, когда посетитель открывает страницу. Документация указывает, что при большом трафике это создаёт нагрузку на сайт. Лекарство - перевести агентов на cron, то есть на запуск по расписанию сервера, не зависящему от посетителей.

Документация Bitrix Framework описывает два режима. «На хитах»: агент срабатывает, когда посетитель заходит на страницу, точность запуска зависит от посещаемости, система обрабатывает агентов по одному, и, цитата, «при большом трафике агенты на хитах создают нагрузку на сайт». «Через cron»: агент запускается точно по расписанию, не зависит от посещаемости, и нагрузка на сайт снижается.

Список агентов лежит в разделе «Настройки > Настройки продукта > Агенты». В документации есть пример: задание cron, которое запускает агентов раз в 10 минут. Настраивает его администратор сервера, и на простом виртуальном хостинге cron может быть ограничен, поэтому уточняйте у хостера.

Один из признаков этой причины - сайт тормозит рывками: часть открытий страницы быстрые, часть внезапно долгие без видимого повода. В отчёте Метрики это видно как большой разрыв между квантилями 50% и 90% по «Ответу сервера». Оговорка: связь «рывки значит агенты» - наш вывод из того, как работают агенты, а не цитата вендора. Рывки дают и другие причины, поэтому вопрос «агенты у нас на хитах или на cron?» нужно задать подрядчику, а не ставить диагноз самим.

Причина 5. Почему тормозит каталог, фильтр или поиск?

Коротко: если «Контакты» открываются быстро, а каталог, фильтр и карточка товара медленно, подозревать стоит запросы к базе. Каталог вырос, а код выбирает лишнее. Вендор описывает это так: «Сначала замедляется отдача страниц, затем растет нагрузка на базу данных». Искать помогает монитор производительности за сутки.

В документации по инфоблокам сказано: проблемы при работе с данными инфоблоков (так в Битриксе называют каталоги товаров, статьи и другие списки) усиливаются по мере роста проекта, потому что растут объём данных и число посещений. Большинство проблем возникает из-за избыточных данных: лишние поля, повторяющиеся запросы, неоптимальные фильтры. Наш вывод из этого: если тормозит один каталог, более дорогой тариф хостинга поможет ненадолго, пока данные снова не вырастут.

Как это ищут инженеры, по документации по оптимизации запросов:

1. В «Настройки > Настройки продукта > Настройки модулей > Монитор производительности» включают запись медленных SQL-запросов. Порог по умолчанию - 0,1 секунды.
2. Вендор рекомендует запускать монитор на одни сутки.
3. Затем смотрят «Настройки > Производительность > Индексы > Анализ индексов»: индекс в базе данных работает как оглавление, по которому запрос находит нужные строки без перебора всей таблицы.
4. Отдельно есть отчёт «Хиты» (Настройки > Производительность > Хиты) и статистика самых нагруженных страниц в панели производительности.

Оговорка из той же документации: не для каждого запроса нужно создавать индекс, иногда проблема в коде компонента. Поэтому «добавим индексы» без анализа - это тоже ускорение вслепую.

Симптом: простые страницы быстрые, а каталог, фильтр и поиск медленные, и стало хуже по мере роста числа товаров или после доработки. График времени ответа по дням в кабинете ARTGK Code помогает связать рост с событием (обновление, выгрузка каталога) и назвать дату, когда сайт «поплыл», а по дате подрядчик найдёт, что менялось.

Причина 6. Сервер отвечает быстро, а страница всё равно грузится долго?

Коротко: тогда сервер ни при чём: тормозит то, что браузеру приходится скачать и выполнить. В настройках главного модуля Битрикса есть блок «Оптимизация CSS»: объединение файлов, минифицированные версии, перенос JavaScript в конец страницы, сжатые копии. Картинки и виджеты - общая тема, она разобрана в другой статье.

В пользовательской документации блок описан так. Объединять CSS-файлы: все файлы стилей сводятся в один. То же есть для JS. Можно подключать минифицированные версии файлов. «Переместить весь JavaScript в конец страницы» ускоряет загрузку, но активные сценарии выполняются уже после загрузки страницы. Можно создавать сжатую копию объединённых файлов в формате .gz.

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

Признак: в Метрике «Ответ сервера» небольшой, а в PageSpeed Insights показатель LCP больше 2,5 секунды. Подробнее о картинках, сторонних скриптах и проверке на телефоне - в статье «Как ускорить загрузку сайта».

Как по симптому найти свою причину?

Коротко: сопоставьте то, что видите, с таблицей. Один симптом указывает на вероятную причину и ничего не доказывает: окончательный диагноз ставят по настройкам и мониторингу на сервере. Таблица подсказывает, что проверять первым, у кого спрашивать и какой раздел админки попросить показать подрядчика.

Последняя строка опирается на встроенный «Монитор качества» (Настройки > Инструменты > Монитор качества). По документации, это чек-лист автоматизированных и ручных тестов веб-окружения, безопасности, производительности и размещения на хостинге.

Какие страницы админки попросить показать подрядчику?

Коротко: разбираться в настройках самому не нужно. Достаточно попросить семь скриншотов из админки: по ним видно, что включено, а что выключено. Если подрядчик отвечает «всё настроено», но скриншотов не даёт, это повод спросить ещё раз, прежде чем заказывать работы. Список ниже можно переслать подрядчику как есть.

Пути указаны так, как они названы в документации 1С-Битрикс.

1. «Проверка системы»: Настройки > Инструменты > Проверка системы. Нужны строки, выделенные красным.
2. «Панель производительности»: Настройки > Производительность > Панель производительности, закладки «Конфигурация» и «Разработка».
3. «Автокеширование»: Настройки > Настройки продукта > Автокеширование.
4. «Композитный сайт»: Настройки > Настройки продукта > Композитный сайт.
5. «Агенты»: Настройки > Настройки продукта > Агенты. К скриншоту добавьте вопрос: агенты работают на хитах или на cron?
6. «Хиты» и результаты монитора производительности за сутки: Настройки > Производительность > Хиты и Настройки > Настройки продукта > Настройки модулей > Монитор производительности.
7. Блок «Оптимизация CSS» в настройках главного модуля.

После любого обновления Битрикса полезно заново пройти тесты «Монитора качества»: вендор прямо называет повторную проверку после обновлений одним из сценариев использования.

Что можно сделать самому, а что только с подрядчиком?

Коротко: самому можно замерить, выяснить версии PHP и MySQL у хостера и собрать скриншоты. Включение кеша и композита на работающем магазине, cron, индексы и оптимизацию CSS и JS делает подрядчик: после каждого изменения нужна проверка. Перед любой правкой нужна резервная копия.

Самому:

• замерить «Ответ сервера» в Метрике и LCP в PageSpeed Insights в режиме инкогнито, а не под администратором;
• спросить у хостера версии PHP и MySQL и есть ли возможность настроить cron;
• собрать семь скриншотов из прошлого раздела;
• записать, когда стало медленно и что менялось на сайте в те дни.

Подрядчику:

• включение и проверка автокеширования и композита на живом магазине (цены, корзина, остатки);
• перевод агентов на cron;
• анализ медленных запросов и индексов;
• включение оптимизации CSS и JS с проверкой всех ключевых страниц.

Критерий простой: если вы не знаете, как откатить изменение, оно не ваше. Один замер тоже не доказательство. Полевые данные в PageSpeed Insights собираются за 28 дней, лабораторный замер на Lighthouse виден сразу, а Метрика по умолчанию показывает квантиль 50%. Сравнивайте одинаковые замеры до и после.

Что по этой теме видно в кабинете ARTGK Code?

Коротко: кабинет смотрит на сайт снаружи, без доступа к админке. Он проверяет сайт каждые 5 минут (288 раз в сутки) и показывает время ответа по дням, а во вкладке «Здоровье» - оценку скорости по замеру Google PageSpeed. Внутрь Битрикса он не заходит: кабинет показывает симптом, а любую из шести причин подтверждает инженер.

Всё ниже мы увидели в демо-кабинете 13 октября 2026 года. Цифры там демонстрационные, это пример на тестовом сайте, а не статистика клиентов, поэтому мы их не приводим.

• Раздел «Мониторинг». Подпись в кабинете: «Проверяем сайт каждые 5 минут». Есть плитка «Время ответа» со средним за сутки и график «Время ответа (мс) - по дням». В «Последних проверках» видно ответ каждой проверки в миллисекундах. По графику заметно, когда сайт начал тормозить и тормозит ли он постоянно или рывками. Про падения сайта подробнее - в статье про мониторинг доступности.
• Вкладка «Здоровье» в карточке сайта. Показатель «Скорость сайта» по шкале от 0 до 100 с пометкой «замер Google PageSpeed» и кнопка «Проверить сейчас».
• Яндекс Метрика. В демо она не подключена: во вкладке «Здоровье» стоит подпись «не подключена - вкладка «Трафик»».
• Кнопки «Поручить задачу» и «Заказать услугу». В маркетплейсе есть подборка «Сайт тормозит - скорость, хостинг».

Чего в кабинете нет: он не заходит в админку Битрикса, не видит кеш, композит, агентов и SQL-запросы, не определяет версию PHP и MySQL и не присылает оповещений о медленной работе. Оповещения о недоступности сайта пока запускаются постепенно. Проверки из таблицы выше выполняет специалист.

Бесплатная проверка сайта даёт стартовую картину: как отвечает сайт снаружи, какая оценка скорости у PageSpeed и где в таблице искать свой симптом. Без карты, вход по коду из письма.

Сколько стоит ускорение и как понять, что стало быстрее?

Коротко: в маркетплейсе кабинета «Ускорение сайта» стоит 14 900 ₽, срок 2-4 дня, с замером «было / стало». «Перенос/настройка хостинга» - 9 900 ₽, 1-2 дня. Правки руками специалиста - 3 500 ₽ в час. Смета приходит до начала работы, оплата только после вашего подтверждения.

Описание услуги «Ускорение сайта» в маркетплейсе: сжатие картинок, включение кеша, удаление лишнего кода, замер «было / стало». Это общая услуга для любого движка. Для Битрикса задачу из таблицы выше (композит, агенты, анализ запросов) специалист оценивает отдельно: перед стартом вы получаете смету в часах. У ARTGK за плечами 20+ лет работы с 1С-Битрикс, но обещать результат заранее никто не может: сколько даст каждая правка, показывает только замер.

Как проверить, что стало быстрее:

1. До правки сохраните «Ответ сервера» из Метрики (квантили 50% и 90%) и результат PageSpeed Insights.
2. После правки повторите те же замеры в тех же условиях.
3. Лабораторный замер PageSpeed покажет изменения сразу, полевые данные собираются за 28 дней, поэтому повторите замер через 28 дней.
4. Следите за графиком времени ответа по дням: если линия не опустилась, правка не помогла.

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

Источники

• 1С-Битрикс, технические требования - 1c-bitrix.ru/products/cms/requirements.php
• Bitrix Framework, «Агенты и фоновые задачи» - docs.1c-bitrix.ru/pages/framework/background-jobs.html
• Bitrix Framework, кеширование - docs.1c-bitrix.ru/pages/performance/caching.html
• Bitrix Framework, композитный сайт - docs.1c-bitrix.ru/pages/performance/composite-site.html
• Bitrix Framework, оптимизация запросов - docs.1c-bitrix.ru/pages/performance/query-optimization.html
• Bitrix Framework, производительность инфоблоков - docs.1c-bitrix.ru/pages/modules/iblocks/performance.html
• Bitrix Framework, Монитор качества - docs.1c-bitrix.ru/pages/advanced/quality-monitor.html
• 1С-Битрикс, пользовательская документация, «Панель производительности» - dev.1c-bitrix.ru/user_help/settings/perfmon/perfmon_panel.php
• 1С-Битрикс, пользовательская документация, «Проверка системы» - dev.1c-bitrix.ru/user_help/settings/utilities/site_checker.php
• 1С-Битрикс, пользовательская документация, «Автокеширование» - dev.1c-bitrix.ru/user_help/settings/settings/cache.php
• 1С-Битрикс, пользовательская документация, настройки главного модуля - dev.1c-bitrix.ru/user_help/settings/settings/settings.php
• 1С-Битрикс, пользовательская документация, «Хиты» - dev.1c-bitrix.ru/user_help/settings/perfmon/perfmon_hit_list.php
• Habr, блог компании Битрикс24 (ранее «1С-Битрикс»), «Как заставить сайт летать» (2012) - habr.com/ru/companies/bitrix/articles/137927
• PHP, поддерживаемые версии - php.net/supported-versions.php
• endoflife.date, MySQL (вторичный источник) - endoflife.date/mysql
• web.dev, Core Web Vitals - web.dev/articles/vitals
• web.dev, Time to First Byte - web.dev/articles/ttfb
• Google, PageSpeed Insights, о данных - developers.google.com/speed/docs/insights/v5/about
• Яндекс Метрика, отчёт «Время загрузки страниц» - yandex.ru/support/metrica/ru/reports/timing
• Яндекс Вебмастер, скорость обхода - yandex.ru/support/webmaster/ru/service/crawl-rate

Узнать, как отвечает ваш сайт на Битриксе снаружи, можно в кабинете ARTGK Code: проверить свой сайт бесплатно.