Битрикс-магазин тормозит на оформлении заказа: аудит за 4 шага

Сайт на Битриксе тормозит на корзине и оформлении заказа, хотя каталог открывается быстро? Обычно виноваты пять вещей: сервер с устаревшим PHP, агенты на хитах вместо cron, разросшиеся таблицы гостевых корзин и событий, включённый монитор производительности и кастомный код без кэша. Аудит проверяет их по порядку и выдаёт правки с приоритетами.

Каталог летает, а оформление заказа стоит: как выглядит проблема 🛒

Пятница, 12:40, у магазина идёт рассылка. Покупатель открывает каталог, страницы отдаются мгновенно. Он кладёт три товара в корзину, нажимает «Оформить заказ» и смотрит на крутящийся индикатор. Через несколько секунд вкладка закрывается, и открывается сайт конкурента.

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

Ставка понятна. Каждый ушедший с оформления покупатель — заказ, трафик на который вы уже оплатили. Менеджер ждёт, пока откроется список заказов в админке, и теряет рабочие часы. Письма с подтверждением приходят с опозданием, и клиенты звонят с вопросом «где мой заказ». Чем больше рекламы вы запускаете, тем сильнее это бьёт.

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

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

Шаг 1. Проверка системы: PHP, память, opcache ⚙️

Начните со встроенного инструмента: «Настройки → Инструменты → Проверка системы». Он за несколько минут показывает, что не так с окружением. Красные и жёлтые пункты здесь не косметика: каждый из них замедляет каждый запрос.

Что искать в первую очередь:

• ✓версия PHP ниже рекомендованной для вашей редакции Битрикса;
• ✓выключенный opcache: PHP компилирует одни и те же файлы заново на каждый запрос;
• ✓малый лимит памяти и времени выполнения скриптов;
• ✓кэш и сессии на медленном диске вместо memcached или Redis;
• ✓настройки MySQL по умолчанию на сервере, который давно перерос эти значения.

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

Шаг 2. Агенты на хитах: почему тормозит случайный посетитель

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

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

Лечится переносом на cron. В файл dbconn.php добавляют define('BX_CRONTAB_SUPPORT', true), а в расписание сервера ставят запуск bitrix/modules/main/tools/cron_events.php раз в минуту. После этого посетители перестают платить временем за фоновые задачи. Правку делайте на копии сайта и проверьте, что агенты действительно выполняются. Заодно откройте список агентов и найдите те, что работают слишком долго или остались от удалённых модулей: их можно отключить.

Шаг 3. Раздутые таблицы и забытый монитор производительности 🗄️

Каждый анонимный покупатель оставляет след в таблицах гостевых покупателей и корзин: b_sale_fuser и b_sale_basket. Агент очистки должен удалять старые записи. Если он не работал (шаг 2 объясняет, почему так бывает), записи копятся годами, и запросы оформления заказа ходят по огромным таблицам. То же с очередью почтовых событий b_event: неотправленные письма лежат в базе и раздувают её.

Проверка занимает минуты: посмотрите размеры таблиц через phpMyAdmin или консоль MySQL. Те, что многократно больше остальных, становятся первыми подозреваемыми. Чистить их вслепую нельзя: сначала резервная копия, потом штатные механизмы очистки.

Отдельная история — панель производительности в разделе «Настройки → Производительность». Пока она включена, каждый хит записывается в базу, а таблицы b_perf_ растут с каждым запросом. Панель включают на время замера и забывают. Через месяцы сайт платит за неё на каждом запросе, а данные никто не читает. Правило простое: включили на несколько часов, сняли отчёт о медленных компонентах и запросах, выключили.

Шаг 4. Кастомный код: обработчики, кэш компонентов, запросы в цикле 🧩

Последним смотрят код. Ищите тяжёлые обработчики событий в init.php, компоненты с отключённым кэшем (в вызове компонента стоит CACHE_TYPE = N) и обращения к базе внутри цикла в шаблоне. Режим отладки Битрикса показывает время каждого компонента на странице, так что кэш-нарушителей видно сразу.

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

Найти виновников помогает панель производительности из шага 3: она сортирует компоненты и SQL-запросы по времени. Но понять, почему запрос тяжёлый и как его переписать, без разработчика на Битриксе не получится.

Чем искать: встроенные инструменты и аудит специалиста 🔍

У каждого инструмента свой обзор и свои ограничения. Вот как они соотносятся.

Разумный порядок такой: сначала бесплатные встроенные средства, потом специалист. Первые закрывают шаг 1 и часть шага 4. Связать находки между собой — понять, что агент очистки корзин не работает из-за хитов, из-за этого таблица выросла, а оформление заказа стало медленным, — быстрее получается у того, кто проходил такой путь не один раз. Именно эту работу делает аудит сайта.

По дороге: форма заказа и 152-ФЗ 🔒

Пока вы в оформлении заказа, проверьте форму. Она собирает ФИО, телефон, адрес и почту, а это персональные данные по 152-ФЗ. Согласие на обработку должно быть отдельной отметкой, которую покупатель ставит сам, рядом нужна ссылка на политику обработки. Ещё вопрос: где физически лежит база заказов. Закон требует хранить персональные данные граждан РФ на серверах в России.

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

Что вы получите от нас и сколько это стоит 📋

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

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

Правки на сервере (cron, PHP, память) делает системный администратор по ставке 3800 ₽/час, объём в часах вы видите до начала работ. Правки в коде оцениваем отдельно по той же схеме.

Начните с малого: откройте «Проверку системы» и посмотрите на красные пункты. Если среди них окажется то, что нельзя поправить из админки, это уже задача для аудита.

❓ Частые вопросы

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

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

Как перенести агенты Битрикса на cron?

В файл dbconn.php добавляют define('BX_CRONTAB_SUPPORT', true), а в расписание сервера ставят запуск скрипта bitrix/modules/main/tools/cron_events.php раз в минуту. После этого посетители перестают запускать фоновые задачи своими запросами. Правку лучше делать на копии сайта и проверить, что агенты выполняются. Если хостинг не даёт доступа к cron, вопрос решается переездом на VPS.

Можно ли оставить панель производительности включённой постоянно?

Нет. Монитор пишет каждый хит в таблицы базы, и сайт тратит на это время при каждом запросе, а таблицы растут. Включайте его на несколько часов, чтобы снять отчёт о медленных компонентах и запросах, затем выключайте и очищайте накопленные данные. Так вы получите нужные данные без постоянной нагрузки на сайт.

Можно ли провести аудит Битрикса самостоятельно?

Базовую часть можно: открыть «Проверку системы», посмотреть агенты и размеры таблиц. Дальше нужны доступ к серверу и понимание кода: cron, настройки PHP и базы, обработчики событий в init.php. Если внутри компании нет админа и разработчика, эту часть быстрее отдать специалисту, который сразу видит связи между находками.

Сколько стоит настройка сервера под сайт на Битриксе?

Работы на сервере выполняет системный администратор, час его работы стоит 3800 ₽. Итог зависит от объёма: перенос агентов на cron и настройка PHP занимают меньше времени, чем миграция на новый сервер. Объём в часах согласуем до начала работ, актуальные условия смотрите на странице тарифов.