Антон Дегтярёвбитрикс24 тормозит: 12 причин и что с этим делать
Жалоба «Битрикс24 тормозит» встречается на каждом втором аудите, и почти всегда за ней стоит не одна причина, а комбинация из двух-трёх. Разбираю по порядку — от простого, что чинится за 5 минут, до системного, что требует пересмотра архитектуры процессов.
сначала проверьте локальный компьютер и браузер
Причина 1 — устаревший браузер или десятки открытых вкладок. Битрикс24 — тяжёлое веб-приложение с постоянным обновлением данных в реальном времени, и на слабом железе с 20+ открытыми вкладками тормозит не портал, а сама вкладка браузера. Проверяю просто: то же самое действие в новой вкладке инкогнито без расширений.
Причина 2 — конфликтующие расширения браузера. Рекламные блокировщики и некоторые VPN-расширения иногда режут запросы к внешним доменам, которые использует портал (CDN, счётчики, вебхуки), — сайт грузится с задержками или часть виджетов не прогружается вовсе. Отключаю расширения по одному и проверяю — обычно виновник находится за 5–10 минут.
Причина 3 — устаревшая версия браузера. Битрикс24 активно использует современные веб-технологии, и на браузере старше 2 лет без обновлений интерфейс может рендериться заметно медленнее, чем на актуальной версии Chrome или Яндекс.Браузера.
Проверить это несложно: открываю вкладку разработчика (F12), вкладку Network, и смотрю время загрузки запросов при открытии карточки сделки. Если запросы к самому порталу выполняются за 200–400 мс, а общее время загрузки страницы всё равно большое — проблема на стороне браузера или локальной сети, а не сервера Битрикс24.
интернет-соединение и сеть офиса
Причина 4 — нестабильный или медленный интернет-канал. Портал постоянно синхронизирует данные, и при канале с пингом выше 150–200 мс или частыми потерями пакетов интерфейс «зависает» на несколько секунд при каждом действии. Проверяю банальным speedtest и пингом до серверов Битрикс24.
Причина 5 — офисный прокси или файрвол, режущий часть трафика к CDN. Встречается в компаниях с жёсткой корпоративной сетевой политикой — часть ресурсов портала грузится через сторонние домены, и если файрвол блокирует их выборочно, конкретные виджеты (например, встроенная телефония или чат) работают медленно, хотя основной портал открывается нормально.
перегруженность полей и списков в crm
Причина 6 — избыточное количество полей на карточке лида или сделки. Видел карточки со 150+ пользовательскими полями, накопленными за годы без ревизии — карточка рендерится заметно дольше, а часть полей давно никто не заполняет. Решение — аудит полей раз в год: то, что не используется полугодиями, выносится в архивную секцию или удаляется.
Причина 7 — списки с фильтром по неиндексированным пользовательским полям на большом объёме данных. На базе от 50 000+ сделок фильтр по кастомному полю без индекса может выполняться заметно дольше, чем фильтр по стандартному полю. Решение — использовать стандартные поля для частых фильтров, а для кастомных полей с высокой частотой фильтрации запрашивать у поддержки Битрикс24 индексацию.
Смежная проблема — дубликаты контактов и компаний, накопленные за годы работы без чистки. Список из 5 000 контактов, где реальных уникальных — 3 000, а остальное дубли, не только засоряет отчётность, но и делает поиск и фильтрацию заметно медленнее. Про чистку дублей я подробно писал в статье про дубликаты контактов в Битрикс24.
перегруженные бизнес-процессы и роботы
Причина 8 — бизнес-процесс с длинной цепочкой синхронных действий на каждое изменение сделки. Если на один переход стадии навешано 10+ роботов, каждый из которых делает запрос (например, к внешней 1С или к API телефонии), интерфейс может «подвисать», пока все действия не отработают.
Решение — разделять синхронные и асинхронные действия: то, что не требует немедленного результата (уведомления, логирование), выносить в фоновые роботы, а не в цепочку, блокирующую переход стадии. Подробнее о том, как правильно проектировать роботов, я писал в статье про роботов и триггеры Битрикс24.
Причина 9 — рекурсивные или зацикленные бизнес-процессы, которые запускают сами себя повторно при определённых условиях. Встречается редко, но при плохом проектировании БП может генерировать сотни фоновых запусков за час, что заметно нагружает портал целиком, а не только карточки, участвующие в процессе.
тариф и лимиты пользователей
Причина 10 — превышение рекомендованного числа активных пользователей для облачного тарифа при высокой интенсивности одновременной работы. На пике нагрузки (утренний час пик у call-центра, например) может ощущаться небольшая задержка отклика интерфейса. Если это регулярно — стоит пересмотреть тариф или разнести нагрузку (часть отчётов строить не в рабочие часы, а по расписанию ночью).
Для коробочной версии причина другая — недостаточные ресурсы сервера (CPU, RAM, диск) относительно числа пользователей и объёма базы. Требования к серверу растут вместе с базой данных, и то, что хватало на старте с 10 сотрудниками, может не хватать на 50.
Отдельно смотрю, не запускаются ли на том же сервере тяжёлые фоновые задачи параллельно с рабочими часами — резервное копирование базы, полная переиндексация поиска или массовый импорт данных. Если такие задачи запланированы на 10 утра вместо ночи, они забирают ресурсы сервера в момент пиковой нагрузки пользователей и создают ощущение общих тормозов, хотя причина разовая и легко переносится на нерабочее время.
интеграции и вебхуки
Причина 11 — синхронная интеграция с внешней системой (1С, сайт, телефония), которая отвечает медленно и блокирует действие в портале, пока не получит ответ. Классика — обмен с 1С, настроенный неоптимально: полная выгрузка каталога вместо инкрементальной синхронизации только изменений. Подробно про типичные ошибки такого обмена я разбирал в статье про ошибки обмена 1С и Битрикс24.
Решение — переводить интеграции на асинхронную схему через очередь заданий там, где это возможно, и не ждать ответа внешней системы синхронно в момент действия пользователя. На одном проекте перевод обмена с 1С с полной синхронизации каталога на инкрементальную (только изменённые позиции) сократил время отклика карточки товара с 4–6 секунд до менее секунды — без единой правки на стороне самого Битрикс24.
коробка — диск и версия
Причина 12 — для коробочной версии: заполненный диск сервера. При остатке свободного места менее 10% многие СУБД (в том числе MySQL) начинают заметно проседать по производительности, а логи и временные файлы Битрикс24 продолжают писаться, усугубляя ситуацию. Проверяю `df -h` в первую очередь при жалобе на коробку — эта причина неожиданно частая и решается за 10 минут очисткой логов и старых бэкапов.
Плюс устаревшая версия ядра или модулей — коробка без обновлений больше года часто работает медленнее актуальной версии просто из-за накопленных неоптимизированных запросов, которые в новых релизах переписаны эффективнее.
как я диагностирую причину по порядку
Не пытаюсь чинить всё сразу — иду по чек-листу от простого к сложному: браузер и вкладки → расширения → интернет-канал → объём полей на карточке → бизнес-процессы с синхронными роботами → интеграции → (для коробки) диск и версия сервера. На 80% обращений причина находится в первых трёх пунктах и чинится в течение дня без привлечения разработчика.
Оставшиеся 20% требуют более глубокого аудита процессов и интеграций — обычно 1–2 дня на диагностику плюс время на исправление конкретной причины, от нескольких часов до нескольких дней в зависимости от сложности. Если тормоза совпали по времени с недавним внедрением или доработкой — почти всегда причина именно в ней, и я в первую очередь смотрю на изменения за последний месяц, а не начинаю аудит с нуля.
как проверить, что тормоза действительно устранены
После исправления конкретной причины прошу заказчика не просто «на глаз» оценить, стало ли быстрее, а зафиксировать время конкретного действия до и после — например, сколько секунд занимает сохранение карточки сделки с 40 полями. Субъективное ощущение «вроде быстрее» часто обманчиво, особенно если проблема была нерегулярной (проявлялась только в час пик).
Дополнительно смотрю на нагрузку через неделю после исправления, а не сразу — часть причин (например, переполнение диска логами) возвращается через некоторое время, если не устранить первопричину, а не только симптом. Если через неделю жалоб не поступало — считаю причину закрытой окончательно.
Полезная привычка — завести короткий журнал: дата обращения, конкретное действие, которое тормозило, и найденная причина. За полгода такой журнал у меня обычно показывает повторяющиеся паттерны — например, что причина 8 (перегруженные бизнес-процессы) всплывает у конкретного клиента после каждой самостоятельной доработки процессов силами внутреннего сотрудника без согласования архитектуры со мной.