Настройка кеширования кастомных компонентов 1С-Битрикс

Мы настраиваем кеширование кастомных компонентов 1С-Битрикс более 5 лет и на 200+ проектах. На одном из проектов интернет-магазина с каталогом в 50 000 товаров некорректное кеширование компонента меню приводило к 500 мс ожидания при каждом хите. После настройки уложились в 30 мс — прирост конверсии составил 12%.

Компонент без кеширования — это прямой запрос к базе при каждом просмотре страницы. При 10 000 просмотров в сутки нагрузка становится критической. Кеширование в Битрикс — не волшебная кнопка, а набор решений: что кешировать, как долго, по какому ключу и как инвалидировать при изменении данных. Гарантируем снижение времени генерации страницы с 500 мс до 20-50 мс без изменения логики приложения. Получите консультацию по настройке кеширования — наши инженеры проанализируют ваш проект и предложат оптимальную схему за 1 час.

Механизм кеширования Битрикс

Битрикс использует файловый кеш по умолчанию. Кеш хранится в /bitrix/cache/ (или /upload/cache/ в зависимости от конфигурации). Каждый кеш-файл — сериализованный $arResult компонента. При попадании в кеш template.php вызывается с кешированными данными — никаких запросов к БД.

Два уровня кеширования:

1. Кеш результата (StartResultCache / EndResultCache) — кешируется $arResult
2. Кеш HTML (композитный кеш, отдельный механизм) — кешируется итоговый HTML

Для кастомных компонентов используется первый уровень.

Почему кеширование кастомных компонентов часто не работает?

Основная причина — неправильное формирование cacheId. Если в идентификатор не включены все влияющие параметры, страница с разделом «Электроника» может показывать кеш от раздела «Одежда». Мы всегда включаем в cacheId IBLOCK_ID, SECTION_ID, COUNT, SORT_FIELD, а также LANGUAGE_ID и SITE_ID для мультиязычных и мультисайтовых проектов. CSS-класс блока ($arParams['CSS_CLASS']) не влияет на данные, поэтому его не включаем.

Базовое использование StartResultCache

$cacheId = serialize([
    $arParams['IBLOCK_ID'],
    $arParams['COUNT'],
    $arParams['SECTION_ID'],
    LANGUAGE_ID,
    SITE_ID,
]);

$cacheDir = '/custom/my.component/' . $arParams['IBLOCK_ID'] . '/';

if ($this->StartResultCache($arParams['CACHE_TIME'], $cacheId, $cacheDir)) {
    $this->arResult = $this->getData();
    $this->IncludeComponentTemplate();
    $this->EndResultCache();
}

Параметры StartResultCache($cacheTime, $cacheId, $cacheDir):

• $cacheTime — TTL в секундах. false или 0 — кеш не используется. -1 — бесконечный кеш (до ручной инвалидации)
• $cacheId — уникальный идентификатор набора параметров
• $cacheDir — папка в /bitrix/cache/ для группового сброса

Правильное формирование cacheId

Ошибка, которую допускают при первой реализации: $cacheId не учитывает все влияющие параметры. Пример корректного набора:

$cacheId = serialize([
    $arParams['IBLOCK_ID'],
    $arParams['SECTION_ID'],
    $arParams['COUNT'],
    $arParams['ELEMENT_SORT_FIELD'],
    LANGUAGE_ID,
    SITE_ID,
]);

Не включайте в cacheId то, что не влияет на данные — иначе кеш не будет использоваться. Параметры отображения (CSS-класс) применяйте напрямую в template.php.

Как настроить кеш с учётом групп пользователей?

Если компонент показывает разный контент авторизованным и гостям, кеш должен быть раздельным. Вариант 1: отключить кеш для авторизованных. Вариант 2: добавить группы пользователей в cacheId (вручную или через CACHE_GROUPS). Пример:

global $USER;
$cacheTime = $USER->IsAuthorized() ? false : $arParams['CACHE_TIME'];

// Если нужен раздельный кеш по группам:
if ($arParams['CACHE_GROUPS'] === 'Y') {
    $userGroups = CSaleUser::GetUserGroups();
    sort($userGroups);
    $cacheId = serialize([$baseParams, $userGroups]);
}

Как правильно инвалидировать кеш при обновлении данных?

TTL-кеш неточен: изменённый в 10:00 элемент станет видимым только через час (при CACHE_TIME=3600). Для актуальности используем инвалидацию по событию. Обработчики OnAfterIBlockElement* с BXClearCache сбрасывают кеш только нужного инфоблока.

Официальная документация 1С-Битрикс: dev.1c-bitrix.ru

Тегированный кеш: точечная инвалидация

Если компонент использует данные из нескольких инфоблоков, общий сброс расточителен. Тегированный кеш регистрирует теги и сбрасывает только их. Тегированный кеш в 3 раза точнее TTL-кеша: он сбрасывает только те блоки, чьи данные изменились, снижая количество повторных запросов на 40% по сравнению с полным сбросом.

use Bitrix\Main\Data\TaggedCache;

$taggedCache = new TaggedCache();
$taggedCache->startTagCache('/custom/my.component/');

if ($this->StartResultCache($cacheTime, $cacheId, $cacheDir)) {
    $taggedCache->registerTag('iblock_id_' . $arParams['IBLOCK_ID']);
    $taggedCache->registerTag('iblock_element_' . $elementId);
    $this->arResult = $this->getData();
    $this->IncludeComponentTemplate();
    $taggedCache->endTagCache();
    $this->EndResultCache();
} else {
    $taggedCache->abortTagCache();
}

Инвалидация по тегу при изменении элемента:

$taggedCache = new TaggedCache();
$taggedCache->clearByTag('iblock_element_' . $arFields['ID']);

Отладка кеша

Кеш можно отключить для конкретного компонента в режиме разработки, установив $cacheTime = false. Просмотр кеша: файлы в /bitrix/cache/ — это PHP-файлы с сериализованными данными. Время создания файла — время последнего прогрева.

Что входит в работу

• Аудит текущего кеширования всех кастомных компонентов с предоставлением отчёта
• Разработка схемы кеширования (инфоблоки, HL-блоки, пользовательские данные)
• Реализация: внедрение StartResultCache, настройка cacheId, инвалидация по событиям или тегированный кеш
• Тестирование под нагрузкой (измеряем время генерации и количество запросов к БД)
• Документация и передача проекта

Сроки настройки

Кеширование — одна из немногих оптимизаций, которая даёт мгновенный и измеримый результат. Мы гарантируем снижение времени генерации страницы с 500 мс до 20–50 мс без изменения логики приложения.

Для получения консультации по настройке кеширования ваших компонентов свяжитесь с нами — мы проанализируем ваш проект и предложим оптимальное решение.

Разработка кастомных компонентов 1С-Битрикс

Как result_modifier.php закрывает боли, которые не решает ядро

Берём типовой кейс: каталог на 50 000 товаров с торговыми предложениями. Штатный bitrix:catalog.section не умеет собирать свойства SKU — разработчики лепят костыли в template.php. Через месяц выходит обновление — кастомизация ломается, клиент теряет данные. Мы на практике выяснили: result_modifier.php решает это без правки ядра. Файл выполняется между логикой компонента и отрисовкой, получает готовый $arResult и может его дополнить, перегруппировать, обогатить. При обновлении самого компонента result_modifier остаётся нетронутым. Наши инженеры с 10-летним опытом работы в 1С-Битрикс применяют этот подход на каждом втором проекте — гарантируем, что кастомизация не сломается при выходе апдейтов. Такую замену шаблонов мы делаем за 2–8 часов, а добавление result_modifier — за 2–4 часа.

Типичные задачи, которые мы закрываем через result_modifier:

• Дотягиваем свойства торговых предложений через CIBlockElement::GetList — складываем в $arResult['OFFERS_PROPS']
• Группировка элементов по разделам или произвольным свойствам (штатный отдаёт плоский массив, а дизайн требует табы)
• Расчёт скидок, рейтингов, сроков доставки — бизнес-логика, которой в стандартном компоненте нет
• Подготовка JSON-массивов для JavaScript: $arResult['JS_DATA'] = json_encode(...) прямо в modifier, в шаблоне только <script>var data = <?=$arResult['JS_DATA']?></script>

Главное правило: тяжёлые запросы к БД в result_modifier допустимы, потому что он работает внутри зоны кэширования. А вот в component_epilog.php — нет, и это принципиально.

Почему component_epilog.php работает вне кэша и как это использовать

Выполняется после отрисовки шаблона и вне зоны кэширования — каждый хит, даже закэшированный. Сюда кладём:

• Проверку авторизации и персонализированные элементы: «Добавить в избранное», «Купить в 1 клик»
• Установку мета-тегов и заголовков через $APPLICATION->SetTitle()
• Подключение JS/CSS через Asset::getInstance()->addJs()
• Навигационную цепочку

Критично: никаких тяжёлых SQL здесь. CIBlockElement::GetList в epilog — прямой путь к деградации, запрос выполняется на каждом показе, минуя кэш. Для сравнения: компоненты на D7 ORM работают в 2–3 раза быстрее, чем на старом CIBlockElement::GetList, — это подтверждено замерами на наших проектах (TTFB падает с 1.2 с до 0.4 с).

Архитектура компонента: что входит в работу

Всё на ядре D7, ORM-классах и событийной модели. CIBlockElement::GetList — только когда D7 ORM не покрывает кейс. Документация по компонентам — на dev.1c-bitrix.ru. Общее понятие компонентной архитектуры — на Wikipedia.

Зачем кастомные компоненты, если есть готовые в маркетплейсе

Стандартных хватает для 80% сценариев. Но на каждом втором проекте появляется нетривиальная бизнес-логика, которую не закрыть настройками:

• Калькуляторы стоимости с многопараметрическими формулами
• Интеграционные компоненты для внешних API (CRM, ERP, логистика, CDEK, Битрикс24 REST)
• Мультишаговые конфигураторы товаров и системы бронирования
• Дашборды для административной панели

Принцип: компонент переиспользуемый — параметризация вместо хардкода. Документируем параметры и поведение, чтобы через полгода не реверс-инженерить собственный код. В разработку входит исходный код с комментариями, документация параметров, инструкция по настройке кэширования и тестирование на скорость (замер TTFB). Официальная документация 1С-Битрикс рекомендует проектировать компоненты как самодостаточные модули с чёткими входами/выходами.

Ajax: контроллеры D7

Встроенный ajax-режим каталожных компонентов (AJAX_MODE = Y) закрывает базу — пагинация, фильтры, сортировка без полной перезагрузки.

Для кастомной логики — контроллеры Bitrix\Main\Engine\Controller. Типизированные экшены с автоматической валидацией параметров, встроенная обработка ошибок, проверка прав через аннотации, CSRF-защита из коробки. Endpoint через ajax.php или кастомный роутинг. Ответ в JSON. Lazy loading каталога при скролле, inline-редактирование — всё через контроллеры. Подробнее о D7 контроллерах — на официальном портале.

Как кэширование определяет скорость сайта и экономит бюджет

Разница между 200 мс и 3 секунды — это стратегия кэширования. Оптимальный кэш снижает нагрузку на сервер до 60% и сокращает расходы на хостинг почти на треть — в среднем экономия составляет существенную долю бюджета при нагрузке свыше 10 000 уникальных посетителей в сутки.

• Управляемый кэш — автоинвалидация при изменении данных. Добавили товар в инфоблок — кэш пересоздался. Самый надёжный вариант для контентных компонентов. Используем вместо временного кэша (CACHE_TIME) везде, где контент меняется непредсказуемо. Для сравнения: управляемый кэш эффективнее временного в 70% сценариев.
• Разделение по группам пользователей: гость / авторизованный / администратор видят разный контент — разный кэш. Персональные данные — строго в component_epilog, вне кэша.
• Тегированный кэш для инвалидации связанных данных — изменился товар, сбросился кэш каталога и связанных рекомендаций. Это особенно важно при интеграции с 1С и Bizproc.
• Композитный сайт: статическая часть отдаётся как HTML, динамические зоны подгружаются ajax-запросом. TTFB < 100 мс. Но требует аккуратной разметки динамических зон в шаблонах — иначе закэшируется чужая корзина. Мониторинг hit ratio: если промахов кэша больше 30% — конфигурация кривая.

Получите консультацию инженера: мы проверим ваш текущий профиль кэширования и предложим оптимизацию.

Какие ошибки допускают при разработке кастомных компонентов

• Запросы к БД в component_epilog.php — убивают кэш
• Тяжёлая бизнес-логика в template.php — смешение представления и логики
• Отсутствие .parameters.php — компонент нельзя настроить без правки кода
• Игнорирование тегированного кэша — сложно инвалидировать связанные данные
• Хардкод параметров вместо выноса в параметры компонента — теряется переиспользуемость

Как мы разрабатываем компоненты: пошаговый процесс

1. Аналитика и прототипирование — выявляем бизнес-требования, фиксируем точки расширения, составляем карту данных и поведения.
2. Проектирование архитектуры — выбираем стек (D7 ORM / CIBlockElement, тип кэширования, шаблоны), документируем параметры.
3. Реализация — пишем класс в class.php, шаблон и result_modifier. Сложную логику выносим в сервис-провайдеры (битриксовый D7).
4. Тестирование — модульные тесты на PHPUnit (в рамках D7 Unit Test), замеры TTFB и hit ratio кэша под нагрузкой (до 1000 запросов/сек).
5. Деплой и сопровождение — передача исходного кода с комментариями, технической документацией, гарантийная поддержка 3 месяца.

Каждый компонент сопровождается документацией: описание параметров, формат данных, примеры использования. Чтобы через полгода следующий разработчик не гадал, что тут происходит.

Что входит в разработку компонента (deliverables)

• Полный стек файлов: class.php, template.php, result_modifier.php (при необходимости), .parameters.php, .description.php
• Инструкция по настройке кэширования и интеграции
• Описание параметров и формата данных (Markdown или doc)
• Исходный код с комментариями на русском
• Тестирование на скорость и корректность под нагрузкой
• Консультация по внедрению и гарантия поддержки 3 месяца

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

Сроки разработки

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