Как Битрикс обрабатывает запрос: пролог, компонент, эпилог

В 1С-Битрикс один и тот же URL проходит несколько слоёв обработки: веб-сервер передаёт запрос PHP, пролог поднимает ядро, страница запускает компоненты, а эпилог завершает формирование ответа. Если искать ошибку только в component.php, легко пропустить причину: неверный контекст появляется в прологе, данные теряются в шаблоне, а лишний вывод ломает эпилог или кеш.

Полный маршрут запроса

Ниже описан типичный сценарий для 1С-Битрикс: Управление сайтом на актуальных ветках ядра 24–25.x. Конкретные файлы и состав подключаемых обработчиков могут отличаться от шаблона к шаблону, но общая последовательность сохраняется.

1. Веб-сервер принимает HTTP-запрос. Nginx или Apache выбирает PHP-скрипт напрямую либо передаёт URL в точку входа после rewrite.
2. Запускается пролог. Подключаются настройки сайта, ядро, автозагрузка классов, соединение с базой и базовый контекст пользователя. На этом этапе система ещё не знает, какой компонент должен вывести основное содержимое.
3. Подключается файл страницы. Обычно это index.php или другой PHP-файл в публичной части сайта. В нём вызываются bitrix/header.php, компоненты и bitrix/footer.php.
4. Выполняется компонент. Он получает входные параметры, читает данные, формирует результат и передаёт его шаблону. Шаблон превращает результат в HTML.
5. Срабатывает эпилог. Завершаются операции страницы, выводятся хвост шаблона и служебные блоки, закрывается контекст запроса.
6. PHP отдаёт ответ веб-серверу. До браузера могут вмешаться буфер вывода, кеш страницы, сжатие и настройки веб-сервера.

Эта схема важна для диагностики. Ошибка «компонент ничего не выводит» может означать пустой результат, неправильный шаблон, ранний выход из страницы или то, что ответ уже взят из кеша.

Что делает пролог

В публичной части сайта пролог обычно появляется через подключение /bitrix/header.php. Этот файл — не просто HTML-шапка. Он подключает системную часть страницы и готовит окружение, в котором дальше работают компоненты.

Два уровня пролога

Внутри стандартной структуры Битрикса полезно различать два понятия:

• prolog_before.php — ранняя инициализация ядра до вывода страницы;
• prolog_after.php — поздняя часть пролога, которая выполняется после базовой инициализации и перед основным содержимым.

Не стоит подключать эти файлы вручную в обычной публичной странице, если задача решается через bitrix/header.php. Ручное дублирование меняет порядок инициализации и может привести к повторному подключению системных файлов.

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

Пролог отвечает не за внешний вид шапки, а за право страницы работать в контексте Битрикса.

Примечание. Буфер вывода — механизм, который временно удерживает отправляемый PHP текст, чтобы система могла обработать или изменить его до передачи веб-серверу.

Как компонент получает управление

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

Последовательность внутри компонента

1. Проверка входных параметров. Битрикс объединяет параметры компонента со значениями по умолчанию и параметрами вызова. Ошибка в имени параметра может не вызвать исключение, а просто изменить поведение.
2. Подготовка данных. Логика компонента обращается к инфоблокам, ORM, настройкам модуля или внешнему источнику. Результат обычно складывается в массив, который передаётся шаблону.
3. Обработка результата. Если в компоненте есть файл result_modifier.php, он может изменить подготовленные данные перед шаблоном.
4. Рендеринг. template.php читает результат и выводит HTML. В этом файле не должно быть запросов к базе без необходимости: шаблон отвечает за представление, а не за сбор данных.
5. Завершение компонента. Файл component_epilog.php, если он предусмотрен шаблоном, выполняется после вывода шаблона. Его используют для действий, которым нужен уже сформированный результат компонента, например для дополнительных служебных операций.

Порядок result_modifier.php и component_epilog.php часто путают. Первый нужен до вывода шаблона, второй — после него. Перенос логики между ними может изменить доступность переменных и поведение кеша.

Где заканчивается компонент и начинается эпилог

После последнего компонента страницы обычно подключается /bitrix/footer.php. Как и header.php, это обёртка стандартного жизненного цикла, а не только набор закрывающих HTML-тегов. Она подключает финальную часть страницы и системный эпилог.

В типовой структуре участвуют epilog_before.php, footer.php и epilog_after.php, но точная цепочка зависит от версии ядра, шаблона и режима работы сайта. Поэтому при разборе проекта сначала откройте фактические файлы в его каталоге /bitrix, а не переносите схему из чужого шаблона.

Что ломается первым

У каждого слоя свои характерные симптомы. Они позволяют сократить поиск от всей страницы до одного участка жизненного цикла.

• Белая страница или ошибка до HTML. Часто проблема находится в ранней инициализации: синтаксическая ошибка, неверный путь, недоступная база или несовместимый код модуля.
• Шапка отображается, а блок пустой. Проверяйте параметры компонента, права пользователя, фильтр и кеш. Сам факт успешного вывода header не означает, что компонент получил данные.
• Данные есть, но HTML неправильный. Ищите ошибку в шаблоне компонента, включая неправильное имя поля или условие, которое скрывает результат.
• Нижняя часть страницы не выводится. Проверьте фатальную ошибку внутри компонента, ранний return, незакрытую конструкцию PHP и файл footer.
• Изменения видны только после очистки кеша. Это может быть кеш компонента, управляемый кеш страницы или композитный режим. Сначала определите, какой слой возвращает старый HTML.

Как измерять путь запроса

Без замеров нельзя честно сказать, какой этап «медленный». Разделите время хотя бы на три участка: до запуска компонента, внутри компонента и после него. Для этого используйте профилирование конкретной версии Битрикса, журнал PHP и средства мониторинга, доступные в административной части.

Сравнивайте минимум два запроса: первый без кеша и повторный с кешем. Записывайте URL, пользователя, размер выборки, состояние кеша и время ответа. Если тормозит только первый запрос, ищите прогрев и сбор данных. Если оба медленные, проверяйте запросы к базе, внешние HTTP-вызовы и тяжёлую логику в шаблоне.

Не измеряйте страницу только в браузере: DevTools показывает итоговый сетевой запрос, но не всегда объясняет, сколько времени заняли PHP, база и внешние сервисы.

Граничные случаи

Прямая страница и AJAX-запрос не обязаны проходить одинаковую цепочку. AJAX-обработчик может подключать только раннюю часть ядра и не использовать обычные header и footer. Подключение полного шаблона в таком обработчике часто приводит к лишней разметке и неожиданным заголовкам.

Та же проблема возникает в CLI-скриптах, агентах и фоновых заданиях. У них нет обычной страницы, поэтому рассчитывать на переменные, пользователя и настройки, которые появились в публичном прологе, опасно.

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

Что делать дальше

Возьмите одну проблемную страницу и составьте для неё карту: точка входа, header, компоненты, footer, кеш и внешние вызовы. Затем отключите кеш только для диагностического сравнения, проверьте время каждого тяжёлого компонента и верните кеш после теста.

Следующий практический шаг — открыть фактические файлы header.php, footer.php и шаблон компонента в вашей версии ядра. Сопоставьте их с документацией API и проверьте, где именно появляется старый HTML или задержка. Инвалидация кеша и настройка композитного режима — отдельные темы; здесь важно сначала восстановить порядок выполнения запроса.