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

Для отримання консультації з налаштування кешування ваших компонентів зв'яжіться з нами — ми проаналізуємо ваш проєкт і запропонуємо оптимальне рішення.