![\"Схема](\"/assets/editorial/2022/bitrix-performance-2022-cache-contract.svg\")
Фраза «компонент закеширован, значит страница быстрая» ломается сразу в двух местах. Она смешивает контракт компонента с итогом всего запроса и объявляет реальную производительность без наблюдения. Цена ошибки — опасные решения: в ключ не попадает условие, влияющее на HTML, шаблон перестают проверять, а следующий симптом снова объясняют кешем. Команда теряет корректность выдачи и не получает ответа, где именно возникла задержка.
\nВстроенный кеш Bitrix полезно рассматривать как договор о зависимости результата, а не как кнопку ускорения. Вопрос модели простой: перечислены ли входы, от которых зависит выдаваемый HTML? Если перечислены, можно планировать узкую проверку ветки компонента. Если нет, изменение останавливается. Ниже учебный пример специально не говорит, читался ли файл кеша, сколько работал PHP или что происходило с базой данных.
\nВ архивной документации CBitrixComponent::StartResultCache второй параметр описан как additionalCacheID. Базовая зависимость включает SITE_ID, имя компонента, имя шаблона и входные $arParams; дополнительное условие передают отдельно. В том же контракте true означает, что результат нужно сформировать, а false — что найден действительный кеш.
Это точный факт о методе, но не измерение страницы. Вызов с ожидаемой веткой не доказывает, что конкретный HTTP-запрос получил cache hit. Для вывода о времени ответа, SQL или PHP нужен отдельный артефакт из конкретной среды: профиль, лог, трасса или повторяемый замер с зафиксированными условиями.
\nSetResultCacheKeys решает соседнюю задачу: определяет, какие части $arResult нужны при встроенном кешировании. Этот метод не добавляет отсутствующее условие в ключ и не доказывает, что шаблон перестал влиять на HTML. Сначала нужно назвать компонент, результат и данные, которые действительно используются при выводе.
| Слой | Что фиксируем | Чего это не доказывает | Первое действие |
|---|---|---|---|
| Маршрут | URL и одинаковый вариант входа | Какой PHP или SQL исполнился | Повторить один вход |
| Компонент | Имя и фактические параметры | Что он единственный источник задержки | Назвать владельца |
| Кеш | Режим и полный список зависимостей | Реальный hit-rate и время чтения | Сверить ключ с output |
| Шаблон | Имя и данные, которые он выводит | Его длительность в миллисекундах | Выбрать измерение границы |
Когда результат зависит от группы посетителя, языка, витрины, прав, фильтра или другого внешнего условия, это не мелкая деталь кеша. Это условие, по которому один HTML допустим, а другой нет. Полный список нельзя угадать по названию компонента: его получают из output contract — из того, что меняет шаблон, и из источника каждого такого значения. Иногда вход уже находится в $arParams, иногда его нужно передать дополнительно, а иногда компонент нельзя рассматривать изолированно.
Практическое правило ревью: каждый фрагмент HTML либо одинаков для всех состояний ключа, либо имеет названную зависимость. Если это не доказано, ключ считаем неполным. Такой stop condition останавливает попытку «ускорить» страницу до того, как один вариант не окажется показан другому посетителю. Сначала корректность выдачи, затем экономия работы.
\nFixture работает не с Bitrix, а с учебным объектом createTeachingRequest. В полном варианте есть visitor-segment; в неполном он отсутствует среди объявленных частей, хотя требуется для output contract. Модель возвращает stop-incomplete-cache-contract и блокирует замену шаблона. Это не эмуляция StartResultCache, не генерация HTML и не тест платформы. Она проверяет только правило: неизвестную зависимость нельзя замаскировать оптимизацией.
import { runBitrixPerformanceFixture } from './upgrade-2022-11.mjs';\nconst report = runBitrixPerformanceFixture();\nif (!Object.values(report.assertions).every(Boolean)) {\n throw new Error('fixture contract failed');\n}\nconsole.log(report.incompleteReport.nextAction);\n// name-missing-cache-input-before-changing-cache\nconsole.log(report.planned.rollback);\n// catalog-gridЯзык результата здесь намеренно строгий. declared-cache-reuse не называется hit, а declared-cache-build не называется miss: fixture знает только объявленные входы учебной модели. Первый объект позволяет запланировать замену владельца шаблона и сохраняет catalog-grid как rollback. Второй останавливает изменение и называет недостающий вход. Для отчёта о production всё равно потребуется новый источник.
Шаблон получает результат и формирует HTML, поэтому именно здесь часто видно, какие данные влияют на выход. Но видимость в коде не делает шаблон причиной задержки. Без профиля нельзя назвать его длительность, а без анализа входов нельзя определить, какие значения должны участвовать в ключе. Корректный промежуточный вывод проще: у шаблона есть владелец и output contract, который нужно рассматривать отдельно от измерения времени.
\nКурс Bitrix различает компонентное, неуправляемое и управляемое кеширование. Это не означает, что режим обновления сам определит все смысловые зависимости HTML. На ревью держите два списка: что делает результат другим и когда результат должен обновиться. Первый описывает ключ, второй — invalidation. Смешивание списков порождает ложные решения: срок жизни подменяет зависимость, а очистка кеша подменяет исправление output.
\nХороший rollback возвращает конкретное изменение: прежний параметр компонента, прежнего владельца шаблона или ранее названную часть ключа. Он не обещает откатить всю платформу. В учебной модели rollback возвращает catalog-grid и снова выдаёт только объявленный evidence без длительности и SQL. Это проверка формы решения, а не измерение продукта.
Если после изменения появился другой output или новое условие, старое сравнение использовать нельзя. Оформите новый контракт явно. Не смешивайте rollback с очисткой всего кеша: она меняет контекст и может скрыть дефект вместо его объяснения. Узкий обратимый diff проще проверить, отменить и передать следующему владельцу.
\nЭта статья не содержит production-кейса, реального пользователя, срока кеша, hit-rate или метрики. visitor-segment — учебное условие, а не свойство конкретного сайта. Источники подтверждают только описанные API и виды кеширования; они не доказывают поведение произвольного самописного компонента и не заменяют документацию его версии.
Следующий шаг — выбрать один компонент и написать его output contract: какие данные меняют HTML, что формирует шаблон, что живёт в $arParams, что приходит извне и как выглядит rollback. Только после этого выбирайте инструмент наблюдения. Если зависимость не доказана, результатом проверки должна быть остановка или сбор недостающего факта, а не объявление страницы быстрой.
Ниже использованы официальные страницы 1С-Битрикс в архивных снимках июня, августа и сентября 2022 года. Текущие плавающие формулировки не выдаются за свидетельство состояния ноября 2022. Учебная fixture поверх документов остаётся локальной моделью и не превращается в отчёт о настоящем сервере.
\n