Метрика №1. Индекс производительности (Монитор производительности)
В административной панели есть инструмент для штатного контроля. Речь идет о мониторе производительности Bitrix, который доступен в админке и показывает общую оценку системы: от конфигурации PHP до работы базы данных. Для перехода нужно пройти по пути: «Настройки» → «Производительность» → «Монитор производительности». В некоторых версиях доступен через раздел «Проактивная защита».
Итоговый балл – это не абсолютная «скорость», а сравнительная оценка конфигурации:
- чем выше значение, тем ближе система к рекомендуемым стандартам Битрикс;
- низкий индекс сигнализирует о проблемах в одном или нескольких слоях системы;
- резкое падение после доработок почти всегда указывает на регресс производительности.
В рамках этого теста оценивается, насколько эффективно PHP-уровень взаимодействует с БД и файловой системой: скорость выполнения SQL-запросов через PHP, корректность работы кеширования, которое снижает количество обращений к БД. Если индекс падает, причина чаще всего находится именно в этой связке:
- неоптимальные запросы увеличивают нагрузку на MySQL;
- перегруженные PHP-скрипты замедляют обработку ответов;
- отсутствие или неправильная настройка кэша усиливает нагрузку на оба уровня.
Монитор производительности – это базовый способ быстро определить, на каком уровне (PHP или БД) возникла деградация системы после изменений в проекте.
Метрика №2. Время отклика сервера (TTFB)
TTFB (Time To First Byte) – один из ключевых показателей скорости сайта. Демонстрирует, сколько времени проходит от запроса пользователя до первого ответа сервера.
Если TTFB высокий, нужно искать причину. Медленный хостинг обычно дает стабильную, но плохую скорость. Скачки показателя часто указывают и на другие проблемы: тяжелые SQL-запросы, кеширование на уровне сервера, сетевые задержки, ошибки в шаблоне и компонентах. Отладка помогает выявить, какие именно участки нагружают систему.
Метрика №3. Ошибки в Журнале событий
Даже если сайт работает, это не значит, что все в порядке. В системном журнале (логах) могут накапливаться ошибки – от предупреждений до критических сбоев.
Красные строки в журнале нередко говорят о неправильной работе агентов, компонентов или обращений к базе данных. Они увеличивают нагрузку и могут приводить к нестабильной работе. Регулярная проверка логов – часть мониторинга качества кода Битрикс. А чистота системного журнала является важным требованием при приемке работ у подрядчика.
Метрика №4. Прохождение «Монитора качества»
Монитор качества 1С Битрикс – встроенный инструмент, который проверяет сайт по десяткам параметров: безопасность, конфигурация, производительность, корректность настроек. Разработчик обязан сдать проект с «зеленым» статусом по всем пунктам проверки. Непройденные пункты мониторинга могут означать проблемы с кэшированием, настройками сервера или указывать на вмешательство в ядро системы.
Метрика №5. Отсутствие правок в ядре (кастомизация)
Важным правилом работы с платформой является сохранение целостности системных файлов. Если программисты меняют штатное ядро, возможны проблемы при обновлениях, конфликты при апдейтах, потеря поддержки корректности. Все кастомные доработки должны располагаться исключительно в папке /local/, что позволяет защитить лицензию и избежать ошибок. Проверить чистоту разработки можно по следующим критериям:
- отсутствие измененных файлов в системных директориях платформы /bitrix/;
- выполнение штатной проверки целостности системы через инструменты админки;
- использование переопределения шаблонов и компонентов через механизм наследования;
- возможность автоматической установки патчей безопасности.
При соблюдении этих требований система сохраняет возможность обновления без утраты функциональности. Если же изменения внесены в ядро, они будут перезаписаны при обновлении, что приведет к ошибкам и нарушению стабильности работы сайта.
В заключение
Заказчик должен вести системный аудит разработки сайта, предварительно важно зафиксировать это требование в технических заданиях и договоре. Исполнители обязаны предоставлять результаты тестов, оценок и исследований других метрик на всех этапах, чтобы мелкие проблемы устранялись своевременно и не превращались в снежный ком. Желательно внедрение собственного технического специалиста, который будет контролировать команду разработчиков, выступая в роли «адвоката» заказчика.
