Страница каталога грузится 6 секунд, сервер мощный, хостинг не жалуется, а клиенты уходят. Без инструментов диагностики начинают гадать: «может кеш не работает», «может база тормозит». Наш аудит производительности даёт точный ответ: где именно теряется время и сколько конкретно можно выиграть. За 10 лет мы провели более 500 аудитов — типовые проблемы повторяются: N+1 запросы, отключённый кеш, отсутствие индексов. Аудит выявляет их за 3-5 дней и даёт конкретный план действий.
Представьте: интернет-магазин на Битриксе, каталог 10 000 товаров, страница категории открывается за 6 секунд. Клиенты уходят, конверсия падает. Внутренние проверки ничего не дают — сервер не загружен, база не тормозит. Единственный системный шаг — провести аудит производительности. Он покажет первопричину тормозов и даст цифры: сколько секунд можно отыграть на каждом этапе. Средняя экономия времени загрузки — 40%.
Как мы диагностируем медленные запросы?
BX_DEBUG — встроенный инструмент Битрикс. В dbconn.php или bitrix/php_interface/init.php:
define('BX_DEBUG', true);
Показывает в нижней части страницы: количество SQL-запросов, время выполнения PHP, объём памяти, попадания в кеш. Норматив: < 50 запросов, < 500 мс PHP-time на странице каталога.
Для тяжёлых запросов применяем EXPLAIN ANALYZE. Медленные запросы логируем через slow_query_log в MySQL или log_min_duration_statement в PostgreSQL (порог 200 мс), затем анализируем план выполнения. Это в 5 раз эффективнее, чем гадать на кофейной гуще без плана. Согласно документации MySQL, использование EXPLAIN ANALYZE сокращает время анализа плана в 2 раза.
Реальный кейс: на одном проекте каталог тормозил из-за N+1 запросов в handmade компоненте. После перехода на GetList с выборкой свойств время сократилось с 4 с до 1.2 с.
Почему Битрикс тормозит на больших каталогах?
N+1 в компонентах. Листинг товаров делает 1 запрос на список и N запросов на цены/свойства. При 50 товарах на странице — 50 лишних запросов к b_iblock_element_property. Решение: select с нужными свойствами или пакетная выборка.
Отключённый кеш. Разработчик отключил кеш во время разработки и забыл включить. Проверяется в настройках компонента и глобально. Включение кеша может сократить время ответа в 3-5 раз.
Без индексов на кастомных таблицах. Пользовательские таблицы создаются без индексов, потом по ним делаются запросы с WHERE — full table scan на миллионе строк.
Тяжёлые агенты в web-потоке. CAgent::CheckAgents() вызывается при каждом хите, если не настроен cron. Агенты с тяжёлой логикой тормозят каждую страницу.
Чем аудит производительности отличается от обычной проверки скорости?
Обычная проверка через онлайн-сервисы показывает только внешние метрики: TTFB, время загрузки ресурсов. Аудит залезает внутрь: профилирует PHP-код, анализирует SQL-запросы, проверяет конфигурацию кэша и сервера. Разница в точности как между тонометром и МРТ — второй видит проблему на уровне кода и данных.
Что проверяем при аудите
| Слой | Что измеряем | Инструмент |
|---|---|---|
| PHP | Время выполнения, memory peak | BX_DEBUG, Xdebug Profiler |
| SQL | Количество запросов, slow queries | BX_DEBUG, slow_query_log |
| Кеш | Hit rate, объём | Bitrix cache stats |
| HTTP | TTFB, размер страницы, ресурсы | Lighthouse, WebPageTest |
| Сервер | CPU, RAM, I/O wait | Zabbix, top, iostat |
Вот пример результатов типичного аудита:
| Метрика | До оптимизации | После оптимизации |
|---|---|---|
| Время загрузки страницы каталога | 6 с | 1,2 с |
| Количество SQL-запросов | 120 | 25 |
| PHP time | 1800 мс | 300 мс |
| TTFB | 800 мс | 150 мс |
Согласно документации 1С-Битрикс по кешированию, включение тегированного кеша может снизить нагрузку на сервер в 5 раз.
Процесс работы
- Сбор метрик — включаем BX_DEBUG, slow_query_log, устанавливаем Xdebug. Снимаем профили на типовых страницах.
- Анализ — разбираем планы SQL-запросов, ищем N+1, проверяем индексы, агенты, настройки кэша.
- Отчёт — готовим таблицу узких мест с оценкой влияния (в секундах) и трудоёмкостью исправления.
- Рекомендации — приоритизированный план: что делать в первую очередь для максимального ускорения.
- Поддержка — при необходимости помогаем внедрить оптимизации (настройка cron, правка компонентов, миграции).
Типичные ошибки при оптимизации
- Настройка cron для агентов не выполнена — каждый хит вызывает
CAgent::CheckAgents(). - Индексы не добавлены на поля, по которым часто фильтруют (price, status, category).
- Кэш компонентов отключён или сброшен без необходимости.
- Gzip-сжатие статики не включено на уровне веб-сервера.
Закажите консультацию, чтобы узнать точные сроки и стоимость для вашего проекта. Свяжитесь с нами — мы готовы провести диагностику вашего сайта.