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

Одна страница может выполнять тяжёлый SQL-запрос. Компонент — пересобирать данные при каждом открытии. Агент — запускаться во время пользовательского запроса. PHP может работать без OPcache, база — ждать дисковую подсистему, а внешний сервис — задерживать ответ на несколько секунд.

Поэтому ускорение сайта лучше начинать не с изменения десятков настроек, а с вопроса:

на каком именно этапе запроса теряется время?

Для этого в 1С-Битрикс есть штатный «Монитор производительности», а серверные и браузерные измерения помогают отделить медленную генерацию страницы от проблем с изображениями, JavaScript и внешними ресурсами.

Если сайт нужен посетителям прямо сейчас

Если рабочий сайт внезапно стал заметно медленнее:

1. Не обновляйте одновременно PHP, MySQL, ядро и модули в надежде ускорить сайт.
2. Не очищайте постоянно весь кеш — так можно временно сделать ситуацию ещё хуже.
3. Зафиксируйте конкретные медленные URL и время проверки.
4. Сравните публичную часть, административный раздел и несколько разных типов страниц.
5. Проверьте загрузку CPU, оперативной памяти, диска и базы данных.
6. Вспомните последние изменения: новый модуль, импорт, интеграция, обновление, обмен, доработка компонента.
7. Только после измерения меняйте конкретный участок системы.

Главный принцип:

измерили → нашли медленный участок → исправили → повторили тот же замер.

Содержание

1. Что значит «1С-Битрикс медленно работает»
2. Сначала определяем масштаб проблемы
3. Используем Монитор производительности
4. Ищем медленную страницу или компонент
5. Проверяем SQL-запросы и базу данных
6. Проверяем кеширование
7. Проверяем агентов и фоновые задачи
8. Проверяем PHP и OPcache
9. Проверяем CPU, память, диск и свободное место
10. Что даёт Композитный сайт
11. Проверяем внешние API и интеграции
12. Отделяем медленный сервер от медленного фронтенда
13. Проверяем результат после оптимизации
14. Частые вопросы

1. Что значит «1С-Битрикс медленно работает»

Фраза «сайт тормозит» может описывать совершенно разные проблемы.

Например:

• сервер долго начинает отдавать HTML;
• только каталог открывается медленно;
• карточка товара медленная, а главная быстрая;
• административная часть зависает при сохранении;
• первая загрузка страницы долгая, повторная — быстрая;
• сайт тормозит только во время обмена или импорта;
• HTML приходит быстро, но браузер ещё долго загружает изображения и JavaScript;
• замедление появляется только при высокой посещаемости.

Эти ситуации нельзя лечить одним способом.

Упрощённо запрос можно представить так:

браузер → веб-сервер → PHP → ядро 1С-Битрикс → компоненты → база данных / кеш / внешние сервисы → HTML → CSS / JS / изображения

Задержка может появиться на любом участке этой цепочки.

Поэтому сначала нужно понять, медленно работает сам PHP-запрос или страница уже получена, но долго отрисовывается в браузере.

↑ К оглавлению

2. Сначала определяем масштаб проблемы

Перед включением подробной диагностики проверяем несколько разных сценариев.

Медленно работает весь сайт

Если одинаково долго открываются главная, каталог, статьи и административный раздел, в первую очередь смотрим:

• загрузку сервера;
• PHP;
• OPcache;
• базу данных;
• дисковую подсистему;
• глобальный код;
• агентов;
• общие серверные настройки.

Медленно работает одна страница

Если остальные разделы быстрые, вероятность общей нехватки мощности меньше.

Проверяем:

• компоненты этой страницы;
• количество SQL-запросов;
• их продолжительность;
• кеширование;
• пользовательский код;
• внешние запросы.

Медленно работает целый раздел

Например, только каталог.

Тогда ищем общую зависимость:

• один компонент;
• один шаблон;
• инфоблок;
• фильтр;
• свойства товаров;
• запросы;
• обработчики событий.

Сайт тормозит периодически

Нужно сопоставить время замедления с:

• обменом с 1С;
• импортом;
• резервным копированием;
• поисковой индексацией;
• выполнением агентов;
• cron-задачами;
• высокой посещаемостью;
• внешними интеграциями.

Если проблема появляется каждый день примерно в одно время, это особенно важный признак фоновой задачи.

↑ К оглавлению

3. Используем Монитор производительности

В 1С-Битрикс есть штатный модуль «Монитор производительности».

Основные инструменты находятся в административном разделе:

Настройки → Производительность

Монитор позволяет анализировать:

• страницы;
• компоненты;
• хиты;
• SQL-запросы;
• кеширование;
• таблицы базы данных;
• индексы;
• настройки PHP;
• сервер базы данных;
• историю замеров.

Это полезнее общей оценки вроде «производительность 30» или «производительность 80».

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

Например:

страница каталога → компонент → 120 SQL-запросов → один запрос занимает большую часть времени

или:

страница → компонент → кеш постоянно пересоздаётся

Так появляется конкретная задача, которую можно исправить.

Перед замером

Лучше заранее определить несколько контрольных URL:

• главная;
• каталог;
• карточка товара;
• информационная страница;
• медленная страница, на которую жалуются;
• административная операция, если проблема находится в админке.

После этого сравнивать одинаковые сценарии до и после изменения.

↑ К оглавлению

4. Ищем медленную страницу или компонент

В Мониторе производительности можно посмотреть статистику по страницам и компонентам.

Если медленно работает конкретный URL, начинаем именно с него.

Для компонента важны:

• время работы;
• количество вызовов;
• SQL-запросы;
• использование кеша;
• повторение одного и того же компонента на странице.

Например, страница может содержать несколько небольших компонентов, каждый из которых отдельно выглядит безобидно.

Но если каждый выполняет по 15 запросов к базе, суммарно страница может делать десятки или сотни запросов.

Другой вариант — один кастомный компонент выполняет тяжёлую операцию при каждом открытии.

Что проверяем в коде

Если монитор уже локализовал компонент:

1. Смотрим, какие данные он получает.
2. Проверяем количество обращений к базе.
3. Ищем повторяющиеся запросы.
4. Проверяем кеширование.
5. Проверяем обработку больших массивов.
6. Проверяем вызовы внешних сервисов.
7. Смотрим обработчики событий, которые запускаются во время работы компонента.

Нет смысла в этот момент настраивать весь MySQL или менять сервер.

Сначала исправляется найденный участок.

↑ К оглавлению

5. Проверяем SQL-запросы и базу данных

Медленные SQL-запросы — одна из типичных причин долгой генерации страниц.

В 1С-Битрикс отчёт находится здесь:

Настройки → Производительность → SQL запросы

Модуль умеет:

• вести журнал SQL-запросов;
• сохранять стек вызова;
• записывать только запросы медленнее заданного времени;
• показывать план исполнения.

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

На что смотреть

Например:

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

Для MySQL дополнительно полезен EXPLAIN — он показывает план выполнения запроса.

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

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

Проверяем сам сервер базы данных

В 1С-Битрикс есть отдельный раздел:

Настройки → Производительность → Сервер БД

Он показывает статистику сервера базы данных и рекомендации по параметрам.

Если тормозят практически все обращения к БД, а не один конкретный запрос, уже имеет смысл проверять:

• нагрузку MySQL;
• память;
• диски;
• блокировки;
• конфигурацию;
• количество соединений;
• расположение базы относительно веб-сервера.

Но сначала отделяем плохой SQL от медленного сервера БД.

↑ К оглавлению

6. Проверяем кеширование

Bitrix Framework поддерживает кеширование компонентов именно для того, чтобы не выполнять одинаковую тяжёлую работу при каждом запросе пользователя.

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

Типичные проблемы

• кеширование отключено;
• время кеша слишком маленькое;
• кастомный компонент вообще не использует кеш;
• в ключ кеша попадают данные, которые постоянно меняются;
• кеш очищается при каждом запросе;
• обработчик слишком часто инвалидирует большие области кеша.

В Мониторе производительности есть отдельный раздел:

Настройки → Производительность → Кеширование

Он помогает посмотреть работу файлов кеша.

Простой диагностический признак

Если первое открытие страницы значительно медленнее последующих, стоит проверить, какую роль играет кеш.

Но это не означает, что нужно просто увеличить время кеширования до огромного значения.

Нужно понимать:

• какие данные можно кешировать;
• когда они должны обновляться;
• какие данные персональны;
• какое событие должно инвалидировать кеш.

Кеш должен уменьшать повторную работу, а не показывать пользователю устаревшие данные.

Не очищайте кеш после каждого изменения

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

Если постоянно очищать весь кеш во время диагностики, можно получить ложное впечатление, что сайт всегда работает медленно.

↑ К оглавлению

7. Проверяем агентов и фоновые задачи

Агенты 1С-Битрикс позволяют выполнять PHP-функции с заданной периодичностью.

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

Поэтому тяжёлый агент способен добавить собственное время к пользовательскому запросу.

Особенно подозрительна ситуация:

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

Проверяем:

Настройки → Настройки продукта → Агенты

Смотрим:

• какие агенты активны;
• как часто они запускаются;
• что именно выполняют;
• нет просроченной очереди;
• нет тяжёлого пользовательского агента;
• не совпадает время запуска со временем замедления сайта.

Для тяжёлых и фоновых задач 1С-Битрикс поддерживает выполнение через cron.

Но переносить все задачи на cron случайной командой не стоит.

Нужно сначала определить:

• какие агенты существуют;
• периодические они или непериодические;
• какой режим сейчас настроен;
• как выполняются почтовые события;
• какой cron уже работает на сервере.

После изменения обязательно проверяем, что задачи действительно продолжают выполняться.

Иначе сайт можно ускорить ценой остановившихся фоновых процессов.

↑ К оглавлению

8. Проверяем PHP и OPcache

По состоянию на 2026 год актуальные продукты 1С-Битрикс требуют PHP 8.2 или выше, а рекомендуемая версия — PHP 8.4 и выше.

Но само по себе переключение PHP на другую версию не является способом диагностики производительности.

Сначала проверяем фактически используемую версию и совместимость проекта.

OPcache

1С-Битрикс рекомендует использовать PHP-акселератор, в первую очередь OPcache.

OPcache хранит скомпилированный PHP-код в общей памяти, поэтому PHP не требуется заново разбирать и компилировать одни и те же скрипты при каждом запросе.

Проверяем:

• OPcache включён или нет;
• достаточно выделенной памяти;
• кеш не переполняется;
• количество кешируемых скриптов соответствует проекту.

Не нужно копировать произвольный набор параметров OPcache из чужой статьи.

Размер проекта, количество PHP-файлов и доступная память отличаются.

Сначала смотрим текущее состояние, потом корректируем конкретный параметр.

Перед сменой PHP

Если используется старая версия и планируется обновление:

1. Сделать резервную копию.
2. Обновить ядро 1С-Битрикс.
3. Обновить стандартные модули.
4. Проверить сторонние решения.
5. Проверить собственный код.
6. Затем менять PHP.
7. После изменения повторить функциональные и производительные проверки.

Более новая версия PHP не исправит плохой SQL-запрос или компонент без кеширования.

↑ К оглавлению

9. Проверяем CPU, память, диск и свободное место

Даже идеально написанный код будет работать медленно, если сервер упёрся в физические ресурсы.

Во время воспроизведения проблемы проверяем:

• CPU;
• оперативную память;
• swap;
• нагрузку диска;
• свободное место;
• MySQL;
• количество PHP-процессов;
• очередь запросов.

На Linux базовое состояние можно посмотреть, например, через системные инструменты:

top

или:

htop

Свободное место:

df -Th

Память:

free -h

Но сами по себе цифры ничего не доказывают.

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

Например:

страница медленная → в этот момент CPU свободен → значит, покупка более мощного процессора вряд ли является первым шагом

или:

во время импорта диск загружен полностью → одновременно начинают замедляться PHP и MySQL

Вот это уже полезная связь.

RAM закончилась — что дальше

Если сервер активно использует swap, сначала выясняем, кто потребляет память:

• PHP;
• MySQL;
• импорт;
• резервное копирование;
• другой процесс.

Не стоит просто отключать swap или резко менять десятки параметров MySQL.

Сначала определяем потребителя.

↑ К оглавлению

10. Что даёт Композитный сайт

Технология «Композитный сайт» ускоряет отдачу страниц пользователю за счёт разделения статической и динамической частей.

Статическая часть может быть отдана из кеша, а динамические зоны загружаются отдельно.

Для подходящих публичных страниц это действительно может заметно улучшить субъективную скорость открытия.

Но Композитный сайт не заменяет диагностику.

Если внутри динамического блока остаётся:

• тяжёлый SQL;
• медленный компонент;
• внешний API;
• неправильное кеширование;

этот участок всё равно останется медленным.

Поэтому неправильный порядок:

сайт тормозит → включаем Композит → считаем проблему исправленной

Правильнее:

измеряем backend → устраняем тяжёлые операции → проверяем кеш → затем используем Композит там, где он подходит архитектуре страницы

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

↑ К оглавлению

11. Проверяем внешние API и интеграции

Сайт может медленно работать даже при быстрых PHP и MySQL.

Например, во время запроса код ждёт:

• CRM;
• платёжный сервис;
• службу доставки;
• API поставщика;
• внешний каталог;
• сервис авторизации;
• другой сайт.

Если внешний HTTP-запрос выполняется синхронно, пользователь ждёт вместе с PHP.

Что искать

В пользовательском коде проверяем:

• исходящие HTTP-запросы;
• таймауты;
• повторные попытки;
• запросы внутри циклов;
• одинаковые запросы к API при каждом открытии страницы.

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

Особенно опасна ситуация без разумного timeout.

Внешний сервис перестал отвечать — и PHP-процесс может долго ждать его, занимая рабочий процесс сервера.

Поэтому при периодических замедлениях интеграции нужно проверять наравне с базой и агентами.

↑ К оглавлению

12. Отделяем медленный сервер от медленного фронтенда

Иногда сервер генерирует страницу быстро, но пользователь всё равно видит долгую загрузку.

Причиной могут быть:

• большие изображения;
• видео;
• тяжёлый JavaScript;
• много CSS;
• сторонние виджеты;
• счётчики;
• шрифты;
• рекламные скрипты;
• внешние ресурсы.

Это уже другая часть диагностики.

В инструментах разработчика браузера открываем Network и смотрим запрос основного документа.

Если HTML приходит долго — продолжаем искать проблему на сервере.

Если HTML приходит быстро, а потом ещё несколько секунд загружаются изображения, JavaScript или сторонние домены — оптимизация PHP или MySQL эту задержку не устранит.

Полезно разделять две задачи:

время генерации страницы на сервере

и

время полной загрузки и отрисовки страницы в браузере

У одного сайта проблемы могут присутствовать сразу в обеих частях.

↑ К оглавлению

13. Проверяем результат после оптимизации

Фраза «стало вроде быстрее» — плохой критерий.

После каждого изменения повторяем тот же сценарий.

Например:

до:

страница каталога → 2,8 секунды → 96 SQL-запросов → один компонент занимает 1,7 секунды

после исправления:

та же страница → повторный замер → сравниваем время → сравниваем SQL → проверяем работу компонента → проверяем функциональность

Важно менять по возможности одну причину за один этап.

Если одновременно:

• поменять PHP;
• изменить MySQL;
• включить Композит;
• перенести агентов;
• очистить кеш;
• переписать компонент;

а сайт станет быстрее, мы так и не узнаем, что именно помогло.

И при следующей проблеме диагностику придётся начинать заново.

Рабочая последовательность:

воспроизвели проблему → измерили → локализовали → изменили конкретную причину → повторили измерение → проверили функциональность

Так оптимизация становится управляемой.

↑ К оглавлению

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

Почему 1С-Битрикс медленно работает даже на мощном сервере?

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

Нужно просто очистить кеш 1С-Битрикс?

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

Поможет включение Композитного сайта?

Композит может ускорить отдачу подходящих публичных страниц, но не исправляет медленный PHP-код, SQL-запросы, внешние API и тяжёлые динамические зоны. Сначала лучше измерить backend и устранить реальные узкие места.

Нужно переносить агентов 1С-Битрикс на cron?

Тяжёлые агенты действительно могут задерживать пользовательские запросы, и 1С-Битрикс поддерживает выполнение агентов через cron. Но сначала нужно проверить текущую схему, сами агенты и расписание. После переноса обязательно контролируется их фактическое выполнение.

Какая версия PHP нужна для 1С-Битрикс в 2026 году?

С 1 февраля 2026 года минимальная версия PHP для актуальных продуктов 1С-Битрикс — 8.2. Рекомендуемая версия — 8.4 и выше. Перед обновлением проверяются ядро, модули, сторонние решения и собственный код.

Что проверять первым, если медленная только одна страница?

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

Нужно ускорить сайт на 1С-Битрикс?

Проверю реальные времена страниц и компонентов, SQL-запросы, кеширование, агентов, PHP, базу данных и нагрузку сервера. Найду участок, на котором теряется время, исправлю причину и повторю измерения после изменений.

Здесь, без регистрации

Через KWORK