Фраза «компонент закеширован, значит страница быстрая» ломается сразу в двух местах. Она смешивает контракт компонента с итогом всего запроса и объявляет реальную производительность без наблюдения. Цена — опасные решения: в ключ не попадает условие, влияющее на HTML, шаблон перестают проверять, а любой следующий симптом объясняют кешем. В итоге команда теряет корректность и не получает диагностику.
Ниже мы рассматриваем встроенный кеш Bitrix как договор о зависимости результата, а не как кнопку ускорения. Вопрос модели простой: перечислены ли входы, от которых зависит выдаваемый HTML? Если перечислены — можно планировать узкую проверку ветки компонента. Если нет — изменение останавливается. Учебная модель намеренно не говорит, читался ли файл кеша, сколько работал PHP или что происходило с базой данных.
Что действительно говорит API компонента
В архивной документации `CBitrixComponent::StartResultCache` второй параметр описан как `additionalCacheID`. Базовая зависимость включает `SITE_ID`, имя компонента, имя шаблона и входные `$arParams`; дополнительное условие надо передать отдельно. В том же контракте true означает необходимость сформировать результат, false — использование действительного кеша. Этот API-факт достаточно точен, чтобы обсудить ключ. Он не даёт права утверждать, что конкретный HTTP-запрос прошёл одну из веток.
`SetResultCacheKeys` решает другой вопрос: какие части `$arResult` нужны при встроенном кешировании. Его нельзя использовать как доказательство, что любой `$arResult` лёгкий или что шаблон ничего не делает. Сначала надо назвать, какой компонент и какой результат разбираются. Потом — посмотреть, совпадают ли состояния, важные для HTML, с теми, что участвуют в контракте. Только тогда разговор о размере, обновлении или структуре результата становится техническим, а не ритуальным.
| Вопрос | Допустимый evidence | Недопустимый вывод | Действие |
|---|---|---|---|
| Как устроен базовый ключ? | архивная API-документация и код компонента | в этом запросе был cache hit | сверить внешние условия |
| Что сохраняется из $arResult? | SetResultCacheKeys и конкретный компонент | шаблон не влияет на страницу | проверить template contract |
| Почему страница медленная? | реальный разрешённый артефакт конкретного маршрута | достаточно прочитать API | собрать источник наблюдения отдельно |
| Можно ли менять кеш? | полный перечень входов и rollback | очистка всего кеша безопасна | сделать один обратимый diff |
Ключ — это часть публичного поведения
Когда результат зависит от группы посетителя, языка, витрины, прав, фильтра или другого внешнего условия, это не «мелкая деталь кеша». Это часть условия, по которому один HTML допустим, а другой нет. Нельзя угадать полный список по названию компонента. Его получают из конкретного output contract: что меняет шаблон и откуда это значение приходит. Иногда вход уже в `$arParams`, иногда его нужно передать дополнительно, иногда компонент вообще нельзя рассматривать изолированно.
Полезное правило ревью: каждый фрагмент HTML либо одинаков для всех состояний ключа, либо имеет названную зависимость. Если оба ответа не доказаны, ключ считаем неполным. Это строгий, но недорогой stop condition. Он останавливает попытку «ускорить» страницу до того, как та станет показывать один вариант другим посетителям. Сначала корректность выдачи, потом экономия работы.
Проверяемый пример: один пропущенный вход меняет решение
Fixture специально работает не с Bitrix, а с объектом `createTeachingRequest`. В полном варианте есть `visitor-segment`; в неполном он отсутствует среди declared parts, хотя требуется output contract. Модель возвращает `stop-incomplete-cache-contract` и блокирует планируемую замену шаблона. Это не эмуляция `StartResultCache`, не генерация HTML и не тест платформы. Это проверка нашего правила: неизвестную зависимость нельзя замаскировать оптимизацией.
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Обратите внимание на язык результата. `declared-cache-reuse` не называется hit. `declared-cache-build` не называется miss. Эти слова часто кажутся безобидными, но они уже сообщают факт о хранении и реальном вызове. Fixture хранит только то, что было задано как учебный вход. Такой запрет делает пример пригодным для ревью: никто не сможет перенести его output в отчёт о production без нового источника.
Маршрут: симптом → причина → проверка → действие
- Симптом. Команда видит непредсказуемую страницу или хочет менять кеш, но не может перечислить, от чего зависит HTML.
- Причина. Контракт ключа заменён предположением: «в параметрах наверняка всё есть» или «кеш общий для всех».
- Проверка базы. Сверьте документированный набор `SITE_ID`, component, template и `$arParams` с конкретным местом вызова.
- Проверка внешних условий. Для каждого отличающегося output назовите источник и способ включить его в договорённость компонента.
- Действие. При полном перечне планируйте один diff и rollback; при пропуске остановите изменение и уточните owner/contract.
- Повтор. После diff повторите тот же список входов. Новый вариант страницы или новая зависимость требуют отдельного решения.
Почему шаблон нельзя вычеркнуть из разговора
Шаблон — не декоративный хвост компонента. Он получает результат и формирует HTML, поэтому именно здесь часто видно, какие данные реально влияют на выход. Но это не означает, что шаблон надо объявить причиной медленной страницы. Без профиля нельзя назвать его длительность, а без анализа входов нельзя понять, что именно потребляет результат. Правильный промежуточный вывод уже полезен: «у шаблона есть владелец и output contract; его нужно рассматривать отдельно от ключа».
Статья не предлагает добавлять логи в каждый шаблон и не выдумывает инструмент Bitrix. В конкретном проекте способ наблюдения выбирается по доступной среде и правилам доступа: исходный код, локальный debug-инструмент, разрешённый профиль или воспроизводимый стенд. Важно сохранить границу: evidence надо привязать к одному владельцу и одному маршруту, а не к слову «страница».
Управляемый кеш не отменяет договор
Курс Bitrix различает компонентное, неуправляемое и управляемое кеширование. Из этого не следует, что управляемый режим сам определит все смысловые зависимости HTML. Он относится к обновлению данных и механизму cache dependencies, а вопрос о том, что участвует в выходе компонента, остаётся проектным. Если HTML зависит от условия, которое не вошло в key contract, автоматическое обновление не превращает это условие в известное.
Поэтому на ревью полезно держать два списка: «что делает результат другим» и «когда результат должен обновиться». Первый описывает ключ, второй — invalidation. Смешивание списков порождает ложные решения: добавляют срок жизни вместо зависимости или очищают кеш вместо исправления output. У каждого списка должен быть владелец, иначе следующий компонент будет копировать случайный набор параметров.
Rollback и границы решения
Хороший rollback не обещает откатить платформу. Он возвращает конкретное изменение: прежний параметр компонента, прежний template owner или ранее названный key part. В модели rollback возвращает `catalog-grid` и снова выдаёт evidence без длительности и SQL. Это напоминает важное свойство: откат проверяет форму нашего решения, но не измеряет продукт. После реального rollback всё равно нужен отдельный повторный сбор артефакта на согласованной границе.
Если после изменения появился другой output или changed condition, не используйте старое сравнение. Новый контракт нужно оформить явно. Иначе можно получить красивую историю о производительности, где сравниваются разные посетители, разные параметры или разные шаблоны. Наличие новых чисел не делает такую историю надёжнее.
Ограничение и следующий шаг
Эта статья не содержит production-кейса, SQL, пользовательского сегмента, срока кеша, hit-rate или метрики. `visitor-segment` — названное учебное условие, а не свойство реального сайта. Источники не доказывают работу произвольного самописного компонента и не заменяют документацию его версии. Их роль ограничена историческим API Bitrix, существовавшим до ноября 2022 года.
Следующий шаг — выбрать ровно один компонент и написать его output contract на одну страницу: какие данные меняют HTML, что формирует шаблон, что живёт в `$arParams`, что приходит извне и как выглядит rollback. Только после этого имеет смысл выбирать реальный инструмент наблюдения. Такая подготовка короче большой оптимизации, но оставляет команде проверяемую основу.
Историческая граница ноября 2022
Ссылки ниже ведут на официальные страницы Bitrix в архивных снимках июня, августа и сентября 2022 года. Это важно: текущая документация могла поменять формулировки или примеры. В тексте не используются поздние советы платформы и не приписывается архивному API поведение, которого он не описывает.
Проверяемые источники
- 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, профилировщиком или рекомендацией для неизвестного проекта.