Когда на вопрос «что тормозит?» приходит ответ «Bitrix», расследование уже потеряло форму. Платформа становится удобным виновником, а конкретный URL, компонент и шаблон остаются без владельца. Цена видна быстро: один человек очищает кеш, другой меняет вёрстку, третий спорит о сервере. После нескольких правок нельзя сказать, что проверяли и какое изменение можно безопасно вернуть.
Полевой маршрут начинается с дисциплины: не искать эффект, а ограничить вопрос. Мы не знаем реальную причину, пока не собрали артефакт. Зато можем записать симптом, выбрать одну границу и исключить неверные выводы. Учебная модель этого пакета помогает проверить последовательность решения: неполный cache contract останавливает diff; полный допускает планирование одного изменения с rollback. Она не создаёт профилировщик и не сообщает время страницы.
Сделайте симптом пригодным для передачи
Плохой симптом: «каталог медленный». Хорошая рабочая заготовка: «для согласованного маршрута и варианта страницы требуется отделить component/cache/template до изменения». В ней нет придуманных миллисекунд, пользователей или результата. Но есть граница, на которую можно назначить владельца. Если реальный пользовательский сигнал известен, запишите его дословно в рабочем тикете рядом с условиями доступа; статья не подменяет такой сигнал своим примером.
Дальше фиксируется исходный контракт: route, вариант, компонент, template owner, параметры и условия, влияющие на HTML. Не нужно сразу знать ответ. Важно, чтобы неизвестное поле не исчезло из записи. Например, неизвестный `visitor-segment` — причина остановиться и выяснить, меняет ли он output. Это дешевле, чем отправить на production правку ключа и только потом обнаружить, что разные посетители получили общий результат.
| Наблюдение | Разрешённая гипотеза | Чего нельзя утверждать | Следующая проверка |
|---|---|---|---|
| Есть один маршрут и вариант | можно выбрать owner boundary | исполнялся конкретный SQL | найти подключение компонента |
| Назван component и template | можно читать их contract отдельно | один из них уже причина | сверить параметры и output |
| Ключ полный по объявлению | можно планировать узкий diff | на сервере был cache hit | собрать реальный артефакт при необходимости |
| Ключ неполный | изменение кеша опасно | кеш не участвует совсем | назвать недостающий input |
| Diff обратим | можно повторить прежний вход | регрессия устранена | сравнить тот же evidence contract |
Разделите четыре ветки до первого решения
Ветка запроса отвечает за вход: какой маршрут и вариант вообще рассматриваются. Ветка компонента — за имя, параметры и владеющий код. Ветка кеша — за зависимость результата и правила обновления. Ветка шаблона — за output, который формируется из результата. Каждая ветка может дать свой артефакт, но один артефакт нельзя механически переносить на остальные. Список шаблона не является списком SQL, а документированный key contract не является результатом network замера.
Если команда использует настоящий профилировщик или лог, это отдельная работа: фиксируются версия, среда, вход, способ запуска и владельцы данных. Здесь таких артефактов нет, поэтому мы не моделируем их поля. Даже «скорее всего запрос в базе» — лишняя фраза, если она не подтверждена. Честное «пока неизвестно» не замедляет расследование; оно защищает от необратимой правки не той ветки.
Проверяемый пример: stop condition важнее красивого diff
Fixture показывает две развилки. В complete contract перечислены базовые части и `visitor-segment`, поэтому учебная модель разрешает запланировать замену template owner и помнит, что вернуть. В incomplete contract этого входа нет. Модель не пытается подобрать TTL или «перестроить кеш»: она возвращает `change-blocked`. Такой отрицательный пример важнее happy path, потому что он проверяет границу решения.
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Запуск проверяет тринадцать assertions о локальных объектах: runtime не стартовал, SQL и duration не собирались, неполный вход назван, change blocked не меняет модель, planned change создаёт отдельную версию и содержит rollback, а rollback возвращает прежний template. В этих assertions нет «страница стала быстрее», «кеш работает» или «профиль чистый». Если нужно проверить такие утверждения, понадобятся реальные, отдельно сохранённые evidence конкретного проекта.
Маршрут: симптом → причина → проверка → действие
- Симптом. Сохраните один согласованный маршрут и вариант. Не добавляйте предполагаемые миллисекунды или SQL, если их никто не измерял.
- Причина как гипотеза. Выпишите четыре возможные границы: request, component, cache, template. Назначьте владельца каждой доступной.
- Проверка контракта. Прочитайте точку подключения компонента, его параметры и шаблон; отдельно назовите внешние условия output.
- Проверка кеша. Сопоставьте список с историческим API `StartResultCache`. Пропущенный input — stop condition, не повод выключить кеш.
- Действие. Выберите одно обратимое изменение на названной границе либо соберите недостающий артефакт без изменения кода.
- Rollback и повтор. Верните один diff при отрицательном результате и повторите исходный contract. Не сравнивайте другой маршрут под тем же названием.
Какие «быстрые» исправления обычно делают хуже
Первое — очистить весь кеш и считать исчезновение симптома объяснением. Это меняет состояние, но не показывает, какая зависимость была важна. Второе — выключить компонентный кеш без оценки output contract. Так можно убрать одну неизвестность и добавить другую нагрузку, а связь с исходной страницей всё равно не доказать. Третье — переписать шаблон только потому, что он виден в коде. Видимость не равна вине.
Четвёртое — собрать все возможные инструменты одновременно. Логи, профили, network, мониторинг и SQL могут быть нужны, но их массовый запуск без вопроса создаёт шум и риск для данных. Начните с одного артефакта, который различит две гипотезы. Если он не различил, не притворяйтесь, что данных достаточно: вернитесь к контракту и выберите следующую границу. Это медленнее в первом абзаце и быстрее через неделю.
Решение должно быть уже диагноза
После evidence легко захотеть исправить всё: ключ, TTL, шаблон, параметры и сервер. Но диагностика ценна только пока сохраняет различение. Если факт указывает на один отсутствующий input, действие — назвать его и проверить contract, а не менять пять компонентов. Если факт относится к template owner, diff должен оставаться в его зоне ответственности. Узкое решение проще проверить, проще отменить и проще объяснить в следующем PR.
В описании изменения оставьте четыре строки: исходный symptom, использованный evidence, конкретный diff, rollback target. Этого достаточно, чтобы reviewer мог спросить о пробеле. Не пишите «ускорили Bitrix» — фраза шире материала. Корректнее: «уточнили контракт кеша компонента» или «заменили один template owner и повторили согласованный вход». Такой результат может быть скромнее, но он не обещает то, чего никто не измерял.
Когда остановка — правильный результат
Остановитесь, если неизвестен маршрут, output меняется по неописанному условию, нет владельца компонента или предложенный инструмент не разрешён в среде. Не компенсируйте пробелы фразой «обычно Bitrix делает так». Историческая документация описывает APIs платформы, но не обязана знать конкретный самописный шаблон, интеграцию или версии проекта. Перенос общего правила на частный случай требует локального доказательства.
Остановка превращается в полезную задачу, если назвать недостающий факт: «нужно выяснить, влияет ли X на HTML и где он должен жить в контракте»; «нужно подтвердить владельца шаблона»; «нужен разрешённый артефакт на одном URL». Такой вопрос можно отдать следующему человеку без легенды о производительности. И он не портит систему необратимой оптимизацией.
Источники и границы ноября 2022
Архивные документы Bitrix ниже проверены как доступные до ноября 2022: API `StartResultCache`, `SetResultCacheKeys` и курс о видах кеширования. Они служат источником только для их собственных контрактов. В статье нет ссылок на нынешние страницы как на исторический факт, нет выдуманного локального кейса и нет технических утверждений о настоящей странице.
Следующий шаг после этой статьи — заполнить матрицу для одного реального маршрута и согласовать, какой артефакт можно собирать безопасно. Лишь затем выбирайте инструмент и изменения. Так «производительность Bitrix-страницы» перестаёт быть названием для тревоги и становится последовательностью проверяемых шагов.
Проверяемые источники
- 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, профилировщиком или рекомендацией для неизвестного проекта.