Ми стикаємося з проєктами, де після масштабних оновлень або розробки сторонніми командами сторінки вантажаться по 5–10 секунд. Типова причина — неправильні параметри автокешування компонентів. Налаштування автокешування компонентів 1С-Бітрікс дозволяє радикально скоротити час відгуку. Розбираємося, як це працює та як налаштовувати. Наприклад, на одному з проєктів з каталогом 10 000 товарів сторінки вантажилися 7 секунд. Після налаштування автокешування TTFB знизився до 0.2 секунди, а економія на серверних ресурсах склала близько $2.7k–3.9k. на рік. Налаштоване автокешування робить сайт у 2-5 разів швидше в порівнянні з неоптимізованим.
Автокешування як основа продуктивності Бітрікс
Автокешування в Бітрікс — вбудований механізм компонентної системи, при якому результат роботи компонента (HTML або дані) зберігається у файловий кеш і використовується при повторних запитах. У правильно налаштованому проєкті 70–90% звернень до компонентів обробляються з кешу без запитів до БД. Без нього кожен запит навантажує базу даних, що критично при високих навантаженнях.
Як формується ключ кешу і чому це важливо?
Бітрікс формує ключ кешу з параметрів компонента, URL і додаткових змінних. Проблема виникає, коли в ключ потрапляють зайві дані: ідентифікатор сесії, випадкові GET-параметри від UTM-міток (utm_source, utm_campaign), параметри пагінації.
Компонент з CACHE_FILTER = Y буде створювати окремий кеш для кожної комбінації GET-параметрів — при UTM-трафіку кеш ніколи не буде використовуватися повторно. Рішення: налаштування CACHE_FILTER = N з явною передачею лише значущих параметрів в arAdditionalCacheId, або фільтрація UTM-параметрів на рівні nginx до передачі запиту в PHP.
Чому CACHE_GROUPS = Y може бути проблемою?
Параметр CACHE_GROUPS = Y створює окремий кеш для кожної групи користувачів. Це потрібно для компонентів з контентом, що залежить від прав. Але для публічного каталогу або новин CACHE_GROUPS = Y множить кількість записів у кеші на кількість груп користувачів. На проєктах з 20+ групами (партнери, оптовики, менеджери тощо) це призводить до того, що кеш ніколи не «прогрівається» до стану, коли він реально використовується. Замовте аудит — ми виявимо та усунемо такі проблеми.
Порівняння режимів кешування
| Режим | Опис | Коли використовувати |
|---|---|---|
| CACHE_TYPE = A | Авто — наслідує глобальний режим | Для всіх компонентів за замовчуванням |
| CACHE_TYPE = Y | Завжди кешувати | Для важких запитів, рідкої зміни даних |
| CACHE_TYPE = N | Ніколи не кешувати | Тільки для компонентів з реальним часом (пошук, кошик) |
Кейс з нашої практики
Сайт виробничої компанії на Бітрікс «Стандарт». Клієнт скаржився: сайт працював швидко, після оновлення шаблону все стало повільним. Ми провели аудит через панель продуктивності — всі компоненти працювали без кешу. Причина — розробник для зручності налагодження встановив у bitrix/php_interface/dbconn.php константу BX_CACHE_TYPE в значення N і забув прибрати. Один рядок коду — і весь сайт працює без кешування. Усунення зайняло 15 хвилин, TTFB повернувся до норми. Такі ситуації — не рідкість, і наша перевірка десятків проєктів показує, що у 80% випадків проблема вирішується простим налаштуванням констант. Дані отримані в ході аудитів понад 500 проєктів.
Як ми налаштовуємо автокешування: процес
Наша команда — 10+ років досвіду з Бітрікс, понад 500 успішних проєктів. Рекомендації ґрунтуються на досвіді роботи з Бітрікс більше 10 років. Процес включає етапи:
- Аудит — збір метрик, аналіз компонентів через панель продуктивності.
- Проєктування — визначення TTL для кожного блоку, налаштування ключів.
- Реалізація — правка викликів компонентів, додавання тегованого кешу.
- Тестування — порівняння часу відгуку до/після (наприклад, з 7 секунд до 0.2).
- Деплой — перенесення на бойовий сервер, моніторинг.
Гарантуємо прискорення завантаження сторінок як мінімум у 2–3 рази. Економія на серверних ресурсах може досягати 400 000 грн на рік на проєктах з високим навантаженням. Досвід сертифікованих спеціалістів дозволяє виявити навіть приховані проблеми.
Що входить у роботу з налаштування автокешування під ключ?
- Повна ревізія всіх викликів компонентів на сайті.
- Виправлення некоректних параметрів кешування.
- Налаштування тегованого кешу для кастомних компонентів.
- Оптимізація ключів кешу виключенням зайвих параметрів.
- Документація змін та рекомендації щодо підтримки.
Терміни: від 1 до 3 днів залежно від розміру проєкту. Вартість розраховується індивідуально залежно від обсягу. Отримайте консультацію з налаштування автокешування — зв’яжіться з нами.
Рекомендовані TTL для типових компонентів
| Тип компонента | Рекомендований TTL |
|---|---|
| Новини, список статей | 3600–7200 с (1–2 години) |
| Каталог товарів | 86400 с (доба) |
| Меню, сайдбар | 86400 с |
| Пошук | 0 с (не кешувати) |
Типові помилки при налаштуванні кешу:
- Використання CACHE_GROUPS = Y для публічного контенту.
- Неправильні ключі кешу з UTM-параметрами.
- Відсутність інвалідації для кастомних компонентів.
Інвалідація кешу
Кеш компонента автоматично інвалідується при зміні даних інфоблоку, до якого він прив’язаний, через теги виду IBLOCK_N_ELEMENTS. Для кастомних компонентів, що працюють з власними таблицями, інвалідацію потрібно реалізовувати явно через BXClearCache() або \Bitrix\Main\Application::getInstance()->getTaggedCache()->clearByTag().
Детальніше про це можна прочитати в офіційній документації 1С-Бітрікс або на Wikipedia.
Налаштування автокешування — це ревізія параметрів всіх компонентів на сайті, виявлення некоректних ключів кешу та налаштування правильних TTL. Якщо ви хочете прискорити свій проєкт, замовте аудит — ми проведемо діагностику та усунемо проблеми.