Сайт на Битриксе тормозит: 8 причин и как проверить самому
За фразой «сайт на Битриксе тормозит» обычно прячутся три разные проблемы. Первая: страница долго открывается у посетителя — он уходит, не дождавшись каталога. Вторая: медленно работает админка — контент-менеджер тратит полдня на то, что должно занимать час. Третья: сайт нормально живёт в будни и ложится, когда приходит трафик с рекламы или рассылки. Причины у них разные, и лечатся они по-разному. Сначала нужно понять, что именно происходит у вас.
Скорость — не перфекционизм, а деньги. Медленная страница стоит заявок: посетитель с телефона ждать не будет. Скорость учитывают поисковые системы. А медленная админка — это оплаченные часы ваших людей.
Сначала измерьте, потом чините
Ощущение «стало медленнее» субъективно: страница могла попасть в кеш браузера, а в офисе просто плохой Wi-Fi. Прежде чем что-то трогать, соберите четыре цифры. Это минут двадцать и без разработчика.
- Монитор производительности Битрикса. В админке: Настройки → Производительность. Запустите тестирование на обычной посещаемости и дайте ему отработать. Битрикс покажет время генерации страниц, число запросов к базе, долю попаданий в кеш и оценку конфигурации. Единственный инструмент, который смотрит внутрь сайта.
- Время генерации страницы. При включённом режиме отладки Битрикс выводит внизу страницы время генерации, расход памяти и число запросов к базе. Ориентир: десятки запросов на страницу — норма, сотни — повод разбираться.
- PageSpeed Insights или Lighthouse. Смотрите мобильную версию: именно её видит большинство посетителей. Ключевая метрика — LCP, время отрисовки главного содержимого экрана. Хорошее значение — до 2,5 секунды.
- TTFB, время до первого байта. Сколько сервер думал, прежде чем начать отдавать страницу. Видно во вкладке «Сеть» в инструментах разработчика браузера. Ориентир — 0,8 секунды и меньше. Если TTFB большой, вопрос не к картинкам и скриптам, а к серверу, коду и кешу.
Логика дальше такая. Большой TTFB при лёгкой вёрстке — сервер и PHP-код: причины 1–4, 7, 8. Маленький TTFB, но страница рисуется долго — фронтенд: причины 5 и 6. Медленная админка при нормальной публичной части — инфоблоки или хостинг.
Восемь причин, которые встречаются чаще всего
1. Выключено кеширование компонентов
Самая частая находка. Разработчик отключил кеш компонента, чтобы увидеть свои правки, и забыл включить обратно. Или в настройках продукта выключено автокеширование — тогда не кешируется вообще ничего.
Как проверить: в настройках продукта посмотрите, включено ли автокеширование. Затем в режиме правки откройте параметры ключевых компонентов на главной и в каталоге: тип кеширования должен быть «Кешировать» или «Авто». Время кеширования в ноль равно выключенному кешу.
Что делать: включить автокеширование, вернуть кеш компонентам, задать разумное время жизни. Заодно убрать с боевого сайта режим отладки.
2. Не включён композитный сайт
Композит отдаёт посетителю сохранённую копию страницы почти мгновенно, а динамические блоки подгружает следом. На главной и в каталоге разница ощутимая.
Как проверить: настройки композитного сайта лежат в настройках продукта. Бывает и обратная ситуация: композит включён, но работает криво — формы теряют данные, корзина показывает чужие товары, личный кабинет отдаёт пустую шапку. Значит, динамические области размечены неправильно.
Что делать: включать композит стоит, только когда правильно выделены персональные блоки: корзина, авторизация, формы с защитой. Несколько часов работы разработчика, зато результат виден сразу.
3. Тяжёлые запросы к инфоблокам
Самая дорогая в исправлении причина и самая невидимая. Типичные случаи: выборка всех элементов инфоблока без фильтра и лимита, вызов GetList внутри цикла по товарам, запрос всех свойств вместо двух нужных, отсутствие индексов под нагруженными свойствами.
Как проверить: в мониторе производительности есть список самых долгих SQL-запросов и страниц с наибольшим числом обращений к базе. Сотни запросов на одной странице каталога — почти наверняка цикл с выборкой.
Что делать: переписать выборки: один запрос вместо цикла, явный список полей, постраничная навигация с лимитом, кеширование результатов. За час не решается.
4. Старый PHP и хостинг ниже требований Битрикса
Сайты, которые никто не трогал несколько лет, часто работают на версии PHP, которую давно не поддерживают. Переход на актуальную сам по себе ускоряет генерацию страниц. Та же история с сервером: мало памяти на процесс, выключен кеш опкода, неудачные параметры базы.
Как проверить: в разделе производительности есть проверка системных требований — она сравнивает настройки сервера с рекомендованными и показывает расхождения. Версию PHP видно там же.
Что делать: сначала убедиться, что ядро Битрикса и код сайта совместимы с новым PHP, проверить на копии и только потом переключать боевой сервер. Обратный порядок — быстрый способ получить белый экран.
5. Картинки в исходном размере
Менеджер загружает фотографию с камеры на четыре мегабайта, а на странице она показывается размером 300 пикселей. Браузер всё равно скачивает все четыре — на мобильном интернете это и есть «долго грузится».
Как проверить: во вкладке «Сеть» обновите страницу и отсортируйте запросы по размеру. Всё тяжелее пары сотен килобайт — кандидат на сжатие.
Что делать: включить в шаблонах ресайз средствами Битрикса, чтобы уменьшенные копии создавались автоматически, сжать уже загруженные картинки и добавить отложенную загрузку тому, что ниже первого экрана.
6. Десятки подключённых CSS и JS
За годы к сайту прирастают счётчики, виджеты обратного звонка, чаты, карты, три версии jQuery и десяток плагинов, половина уже не нужна. Каждый файл — задержка, а сторонний скрипт ещё и блокирует отрисовку, пока грузится с чужого сервера.
Как проверить: во вкладке «Сеть» посчитайте запросы к css и js. Lighthouse отдельно показывает скрипты, блокирующие отрисовку, и неиспользуемый код.
Что делать: начните со штатного объединения и сжатия стилей и скриптов. Дальше: убрать виджеты, которыми никто не пользуется, и перенести счётчики в отложенную загрузку.
7. Общий хостинг не тянет
На дешёвом общем хостинге сайт делит процессор и диск с сотнями чужих. Признак характерный: скорость разная в разное время суток, а монитор производительности показывает нормальный код при плохом времени ответа.
Как проверить: замерьте TTFB главной утром, днём и вечером. Разброс в разы значит, что дело в соседях по серверу, а не в вашем коде.
Что делать: переезд на отдельный сервер с SSD и настройкой под Битрикс. Разовая работа, обычно вместе с обновлением PHP.
8. Правки в ядре и лишние модули
Когда подрядчик правил файлы прямо в /bitrix/, сайт перестаёт обновляться: обновление затирает правки, поэтому ядро годами не трогают. Отдельная беда — обработчики событий на каждый хит и модули, которые включены, но не используются.
Как проверить: сравнить файлы ядра с эталонной поставкой той же версии — это делает разработчик. Косвенный признак: версия ядра сильно отстаёт, а в списке модулей есть незнакомые.
Что делать: вынести правки в /bitrix/php_interface/ и шаблон, отключить ненужные модули, и только после этого обновлять ядро. Порядок важен.
Что чинится за час, а что — проект
Прежде чем платить за «ускорение», посмотрите, что из найденного относится к быстрым работам.
| Причина | Сложность | Нужен доступ к коду |
|---|---|---|
| Выключено кеширование компонентов | Быстро | Нет, хватит админки |
| Не включён композитный сайт | Полдня | Да |
| Тяжёлые запросы к инфоблокам | Проект | Да |
| Старый PHP и настройки хостинга | Полдня, дольше при несовместимом коде | Да, и к панели хостинга |
| Неоптимизированные картинки | Полдня | Да |
| Десятки CSS и JS | Быстро или полдня | Частично |
| Общий хостинг | Проект | Да |
| Правки в ядре и лишние модули | Проект | Да |
Две верхние строки владелец закрывает сам за час. Остальное требует разработчика, и честная оценка часов тут важнее обещания «ускорим за день».
Когда одной оптимизацией не обойтись
Иногда включить кеш и сжать картинки достаточно. Но если ядро не обновлялось годами, правки лежат прямо в /bitrix/, а кто делал сайт — уже не вспомнить, точечное ускорение превращается в лотерею. Включаете композит — ломается корзина. Обновляете PHP — падает старый модуль. Каждая правка вслепую стоит часов, и платите вы дважды.
Дешевле начать с аудита: понять состояние сайта целиком — ядро, модули, безопасность, хостинг, производительность — и получить список проблем по приоритетам с оценкой в часах. Дальше решаете вы: чинить своими силами, заказать работы по списку или отдать сайт на поддержку по подписке, где обновления ядра, бэкапы и мониторинг идут сверх часов на задачи. Если оформите подписку в течение 30 дней после отчёта, стоимость аудита зачтём в первый месяц.
С чего начать
Пройдите четыре замера из начала статьи — этого хватит, чтобы говорить с подрядчиком не про ощущения, а про цифры. Если картинка получилась пёстрой или доступа к коду нет, закажите аудит: 30 000 ₽, 3 рабочих дня, на выходе отчёт с проблемами по приоритетам и оценкой в часах на каждую. После заявки ответим письмом в течение одного рабочего дня, уточним детали по доступам и пришлём счёт и срок.