Настройка кеширования кастомных компонентов 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 мс без изменения логики приложения.

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