Медленную Bitrix-страницу часто объясняют одним словом: «Bitrix». В нём исчезают маршрут, компонент, вариант шаблона и настройка кеша. Цена такой формулировки — не только спор в чате. Можно отключить кеш на всей странице, переписать шаблон вслепую или поднять ресурсы, а исходный симптом останется на месте. Следующему человеку достанется больше кода и ни одного факта о том, где искать дальше.
Начинаем не с оптимизации, а с маленького контракта evidence. Для одного URL записываем: какой маршрут открыт, какой компонент рассматриваем, какой шаблон объявлен, какие входы влияют на HTML, какую ветку кеша мы ожидаем проверить и куда откатывается один небольшой diff. Это не SQL trace и не профиль. Но такой список не позволяет выдать общую гипотезу за причину.
Четыре слоя вместо одного виновника
У страницы есть как минимум четыре инженерные границы: вход запроса, компонент, решение о встроенном кеше и шаблон, который формирует HTML. Они идут рядом, но не взаимозаменяемы. Ошибка в параметрах компонента не доказывает тяжёлый шаблон. Объявленный режим кеша не доказывает, что на конкретном хите был cache hit. А большой HTML не позволяет без отдельного наблюдения назвать источник данных или SQL-запрос.
Документация Bitrix для `StartResultCache` задаёт полезную, но узкую рамку: метод возвращает false при действительном кеше и true, когда результат нужно сформировать. Она также перечисляет базовые части зависимости кеша: сайт, компонент, шаблон и `$arParams`; дополнительные условия должны быть переданы отдельно. Это знание о контракте компонента, не измерение страницы. Поэтому в заметке слова «reuse» и «build» остаются учебными ветками, а не отчётом живого сервера.
| Слой | Какой факт записать | Что этот факт не доказывает | Первое действие |
|---|---|---|---|
| Маршрут | URL и вариант входа | какой PHP-код или SQL исполнился | повторить один и тот же вход |
| Компонент | имя и параметры, которые разбираются | что он единственный источник задержки | назвать владельца компонента |
| Кеш | режим и полный список входов ключа | реальный hit-rate или чтение файла | проверить неполный ключ |
| Шаблон | имя шаблона и его output contract | стоимость рендера в миллисекундах | собрать один артефакт именно на этой границе |
Сначала сохраняем evidence, потом меняем код
Заведите короткую карточку без оценок: `route=/catalog/`, `component=catalog.section`, `template=catalog-grid`, `cache inputs=SITE_ID, component, template, arParams, visitor-segment`, `rollback=catalog-grid`. Если один из этих пунктов неизвестен, так и пишем «неизвестен». Особенно важен вариант посетителя или другой внешний признак, если он меняет HTML. Его нельзя тихо спрятать в фразу «для пользователя всё по-другому»: это либо часть ключа, либо причина остановить изменение до уточнения.
После карточки выбирается один вопрос. Например: «входит ли visitor-segment в объявленный ключ?» Он лучше вопроса «почему Bitrix медленный», потому что на него есть конечный ответ. Если входа нет, не меняем TTL, не очищаем все кеши и не объявляем шаблон виновным. Сначала уточняем контракт. Если вход назван, следующий факт выбирается на уже обозначенной границе: исходный код компонента, шаблон или разрешённый инструмент проекта.
Проверяемый пример: модель не притворяется страницей
Ниже запускается только fixture этого пакета. Она создаёт два JavaScript-объекта: один с полным набором объявленных частей ключа, другой без `visitor-segment`. Никакого Bitrix runtime, HTTP, PHP, файлового кеша, SQL, HTML или времени внутри нет. Поэтому выход `declared-cache-reuse` означает ровно «так названа ветка учебной модели», а не «сервер нашёл кеш».
import { runBitrixPerformanceFixture } from './upgrade-2022-11.mjs';
const report = runBitrixPerformanceFixture();
if (!Object.values(report.assertions).every(Boolean)) throw new Error('fixture contract failed');
console.log(report.incompleteReport.nextAction);
// name-missing-cache-input-before-changing-cache
console.log(report.planned.rollback);
// catalog-gridПервый объект создаёт отдельную учебную версию с новым template owner и сохраняет `catalog-grid` как rollback. Второй останавливает изменение с `name-missing-cache-input-before-changing-cache`. Это сознательно полезнее фальшивого успеха: в реальном проекте именно недостающий вход может делать безопасную на вид правку неверной для части HTML. Fixture проверяет договорённость о следующем действии, а не платформу.
Маршрут: симптом → причина → проверка → действие
- Симптом. Зафиксируйте один маршрут и один видимый признак без объяснения причины: «на /catalog/ нужно исследование», а не «Bitrix долго отвечает».
- Причина гипотезы. Разложите её на request, component, cache и template. Нельзя одним наблюдением подтвердить сразу четыре слоя.
- Проверка контракта. Назовите компонент, шаблон, параметры и внешние условия, влияющие на HTML. Для встроенного кеша сверяйте их с API-контрактом Bitrix.
- Один артефакт. Выберите разрешённый исходник, лог или профиль, который существует в проекте. Не создавайте фиктивный SQL trace из догадки.
- Малое действие. Меняйте один владеемый параметр или шаблон только после достаточного evidence и заранее названного rollback.
- Повтор. Снова соберите тот же контракт. Если маршрут или вариант изменились, это новый случай, а не результат прежней правки.
Кеш — не переключатель скорости
В Bitrix есть компонентное, неуправляемое и управляемое кеширование; это разные механизмы с разными условиями обновления. Поэтому совет «включите кеш» слишком широк. Встроенный компонентный кеш может быть важен для выбранного блока, но не заменяет проверку шаблона, входных параметров и актуальности результата. Если продукт требует разный HTML для разных условий, цена неполного ключа выше, чем цена дополнительного вопроса на ревью.
Есть и обратная ошибка: увидев вероятность устаревших данных, разработчик выключает кеш полностью. Это меняет сразу несколько переменных и делает следующий разбор хуже. Правильнее зафиксировать, какая зависимость должна участвовать в ключе, кто очищает или обновляет результат и какой пользовательский output допустим. Только после этого обсуждать срок жизни, tagged cache или отказ от кеша на конкретной границе.
Rollback должен быть частью первого diff
Обратимость здесь практична. Если вы меняете шаблон компонента, заранее сохраните прежнее имя, владельца и условие повторной проверки. Откат — это не «вернуть всё как было после релиза», а конкретный маленький diff: восстановить прежний шаблон или параметр и повторить тот же вход. Не смешивайте с rollback очистку всего кеша: это разрушает контекст и может скрыть дефект вместо его объяснения.
Если evidence неполный, тоже есть безопасный rollback: не выполнять оптимизацию. Остановка не означает, что проблемы нет. Она означает, что материал пока не отделяет шаблон от компонента или контракт ключа от наблюдения страницы. Следующий шаг — не новая настройка, а сбор недостающего названного факта с владельцем и способом воспроизведения.
Границы и следующий шаг
Материал не утверждает, что конкретная страница стала быстрее, что Bitrix выполняет SQL в определённой последовательности или что у проекта есть cache hit-rate. В нём нет реального URL, пользователя, запроса, профиля, срока, скриншота и результата. Архивные документы Bitrix подтверждают только описанные API и кешевые зависимости, доступные до ноября 2022 года.
Следующий рабочий шаг — выбрать одну страницу и заполнить карточку evidence из шести полей. На ревью спросить не «что тормозит?», а «какой слой и какой факт это различит?». Если ответ появляется, планируется одно обратимое изменение. Если нет — работа продолжается сбором материала, а не очередной оптимизацией наугад.
Историческая граница ноября 2022
Для исторической части использованы только архивные снимки официальной документации 1С-Битрикс: август и сентябрь 2022 для API компонента и июнь 2022 для курса о кешировании. Текущие страницы платформы сознательно не используются как свидетельство состояния ноября 2022. Учебная fixture поверх документов остаётся собственной локальной моделью.
Проверяемые источники
- 1С-Битрикс: CBitrixComponent::StartResultCache, архивный снимок 27 сентября 2022 года — официальная документация Bitrix, доступная до ноября 2022 года. Описывает возврат false при действительном кеше, true при недействительном, а также базовые части зависимости: SITE_ID, компонент, шаблон и $arParams.
- 1С-Битрикс: CBitrixComponent::SetResultCacheKeys, архивный снимок 15 августа 2022 года — официальная документация Bitrix, доступная до ноября 2022 года. Описывает список частей $arResult, которые сохраняются при встроенном кешировании; не задаёт производительность конкретной страницы.
- 1С-Битрикс: Кеширование, архивный снимок 29 июня 2022 года — официальный учебный материал Bitrix в историческом snapshot. Он различает компонентное, неуправляемое и управляемое кеширование; не является trace, профилировщиком или рекомендацией для неизвестного проекта.