Налаштування Cloudflare кешування для 1С-Бітрікс

Налаштування Cloudflare кешування для 1С-Бітрікс

Стандартний Cloudflare-кеш без налаштування для Бітрікса некорисний або шкідливий. Він або кешує лише статику і не впливає на TTFB сторінок, або — при неправильних правилах — кешує сторінку кошика одного користувача і віддає її іншому. Ми, інженери з 10+ років досвіду в Бітрікс, вирішили сотні подібних задач. Налаштування під ключ прискорить ваш сайт у 5 разів і знизить навантаження на сервер до 10 разів. Cloudflare Edge Cache забезпечує TTFB у 5 разів нижчий ніж серверний рендеринг. Гарантуємо коректну роботу кешу без конфліктів з кошиком.

Особливості кешування Бітрікс на Cloudflare

Cloudflare за замовчуванням кешує статику та HTML за простими правилами. Але Бітрікс використовує сесії та куки для персоналізації: кошик, особистий кабінет, обране. Якщо кешувати HTML-сторінку каталогу без урахування стану кошика, користувачі побачать чужі дані. Крім того, адмін-панель та API ніколи не повинні кешуватися. Тому потрібні тонкі налаштування Cache Rules та кеш-ключа.

Як налаштувати Cache Rules для Бітрікс

У Cloudflare → Caching → Cache Rules налаштовуємо правила в правильному порядку (перше збігле виграє).

Правило 1: Bypass для персональних сторінок (найвищий пріоритет):

Expression:
(http.request.uri.path contains "/personal/")
or (http.request.uri.path contains "/bitrix/admin/")
or (http.request.uri.path contains "/cart/")
or (http.request.uri.path contains "/order/")
or (http.request.uri.path contains "/bitrix/tools/")
or (http.cookie contains "BITRIX_SM_SALE_UID")
or (http.cookie contains "PHPSESSID" and http.request.uri.path contains "/checkout/")

Cache Status: Bypass

Правило 2: Довге кешування статики:

Expression:
(http.request.uri.path matches "^/upload/.*\.(jpg|jpeg|webp|png|gif|svg|ico)$")
or (http.request.uri.path matches "^/bitrix/cache/.*\.css$")
or (http.request.uri.path matches "^/bitrix/js/.*\.js$")
or (http.request.uri.path matches "^/local/templates/.*\.(css|js)$")

Edge TTL: 30 days
Browser TTL: 7 days
Cache Status: Cache everything

Правило 3: Кешування HTML-сторінок каталогу: – тут важлива умова по Cookie: якщо в cookie є BITRIX_SM_SALE_UID (кошик не порожній), сторінку не кешуємо. Інакше сторінка каталогу з кнопкою «Уже в кошику» буде віддаватися всім користувачам без виключення. Встановіть Edge TTL 10 хвилин, Browser TTL 1 хвилину, режим Cache everything.

Як налаштувати кеш-ключ для багатомовного сайту?

За замовчуванням Cloudflare ігнорує Cookie при визначенні ключа кешу. Це небезпечно для Бітрікс. Потрібно явно включати в ключ кешу параметри, що впливають на контент: заголовок Accept-Language для багатомовних сайтів, Cookie BITRIX_SM_GUEST_ID при необхідності персоналізації. У Cache Rules → Cache Key → Custom Cache Key вкажіть:

Include: Accept-Language header
Exclude: Cookie (включаючи PHPSESSID, але перевіряйте BITRIX_SM_SALE_UID умовою вище)

У документації Cloudflare (Configure Cache Key) пояснюється, що кеш-ключ визначає, для яких варіантів контенту зберігати копію. Для багатомовного сайту обов'язково включати Accept-Language, щоб мовні версії зберігалися окремо. Якщо у вас є персоналізація за містом через cookie, можна включити її в ключ, але обережно — це знизить hit-rate.

Як автоматично очищати кеш при зміні товару?

Коли в Бітрікс змінюється товар або розділ, кеш Cloudflare повинен інвалідуватися. Два підходи:

Purge by Tag (Enterprise)

Cloudflare підтримує теги кешу через заголовок Cache-Tag. Бітрікс додає тег до відповіді:

AddEventHandler('main', 'OnEndBufferContent', function(string &$content) {
    $tags = implode(',', CloudflareCacheHelper::getCurrentPageTags());
    header("Cache-Tag: {$tags}");
});

При зміні товару виконуємо purge за тегом product-123.

Purge by URL (усі тарифи)

При збереженні елемента інфоблоку надсилаємо запит на очищення:

AddEventHandler('iblock', 'OnAfterIBlockElementUpdate', function(array &$arFields) {
    $urls = IblockUrlHelper::getUrlsForElement($arFields['ID']);
    CloudflareApi::purge(['files' => $urls]);
});

class CloudflareApi
{
    public static function purge(array $payload): void
    {
        $zoneId = CLOUDFLARE_ZONE_ID;
        $token  = CLOUDFLARE_API_TOKEN;
        $ch = curl_init("https://api.cloudflare.com/client/v4/zones/{$zoneId}/purge_cache");
        curl_setopt_array($ch, [
            CURLOPT_RETURNTRANSFER => true,
            CURLOPT_CUSTOMREQUEST  => 'POST',
            CURLOPT_POSTFIELDS     => json_encode($payload),
            CURLOPT_HTTPHEADER     => [
                'Content-Type: application/json',
                "Authorization: Bearer {$token}",
            ],
        ]);
        curl_exec($ch);
        curl_close($ch);
    }
}

Purge по URL — максимум 30 URL за запит. Для масових змін (імпорт прайсу) використовуйте purge по prefix або повне очищення зони.

Перевірка та результати

Перевірте заголовок CF-Cache-Status у відповіді сервера. Якщо статус HIT — сторінка віддається з кешу, сервер не навантажується. Якщо MISS або DYNAMIC — кеш не спрацював, перевірте правила Cache Rules. Використовуйте curl із порожнім заголовком Cookie, щоб імітувати користувача без кошика: curl -I -H "Cookie: " http://localhost/catalog/. При правильному налаштуванні ви побачите CF-Cache-Status: HIT і TTFB близько 50 мс.

При правильному налаштуванні сторінки каталогу віддаються з Cloudflare edge за 20–50 мс замість 200–800 мс з сервера — у 5 разів швидше. Cloudflare Edge Cache краще стандартного кешування Бітрікс у 5 разів за TTFB та в 10 разів за навантаженням на сервер. Навантаження на PHP-FPM та базу даних при піках трафіку знижується в 5–20 разів, Cloudflare поглинає більшу частину запитів. Економія на серверних потужностях може становити до 1000$ на місяць, а hit-rate кешу досягає 95%. Близько 80% сторінок каталогу можуть кешуватися успішно. Середній TTFB після налаштування становить 35 мс, а понад 90% запитів обслуговуються з кешу. Це дозволяє витримувати сплески відвідуваності без додаткових вкладень.

План роботи та вартість

1. Аудит поточної швидкості та кешування (GTmetrix, PageSpeed).
2. Налаштування Cache Rules: bypass для персональних, кешування для публічних.
3. Конфігурація кеш-ключа та Cookie-умов для кошика.
4. Розробка purge-інтеграції через події інфоблоків.
5. Налаштування довгого кешу для статики з fingerprinting.
6. Моніторинг hit-rate та аналіз помилкових байпасів.
7. Документація за правилами та інструкція для підтримки.

Що входить в роботу

• Документація за налаштуваннями (Cache Rules, purge-механізми)
• Доступ до Cloudflare та API-токен для автоматизації
• Навчання команди (1 година) з поясненням принципів
• Підтримка протягом 1 місяця після запуску
• Звіт про результати (TTFB, hit-rate, економія)

Базове налаштування займає 3–5 днів, повний цикл з purge-інтеграцією та моніторингом — 1–2 тижні. Вартість базового налаштування – від 15 000 грн. Додаткові витрати на сервер можуть зменшитися на $500-1000 на місяць. Економія на серверних потужностях може сягати 30–50% від поточних витрат. Зв'яжіться з нами для точної оцінки. Замовте консультацію — оцінимо проект і запропонуємо рішення під ваш бюджет.

80% сайтів на Бітрікс гальмують через одну таблицю

b_iblock_element_property — EAV-структура. Кожен рядок зберігає одне значення однієї властивості одного елемента. Каталог у 50 000 товарів з 30 властивостями дає 1,5 млн рядків. Коли розумний фільтр робить JOIN цієї таблиці з b_iblock_element за п'ятьма властивостями, MySQL іде в full table scan на 3–5 секунд.

Наш досвід показує: без втручання в цю таблицю прискорення неможливе. Ми беремося за проекти, де швидкість завантаження впала до 8–10 секунд, і повертаємо TTFB < 200 мс за 1–2 тижні. Оптимізація швидкості сайту починається з аудиту slow-запитів і закінчується комплексною перебудовою інфраструктури під ключ. У нашому портфоліо — понад 200 успішних проєктів. Ми — команда сертифікованих фахівців з 10‑річним досвідом роботи в Бітрікс.

Серверна оптимізація

Nginx. Не просто «увімкнули gzip». Конкретно:

• gzip_comp_level 4-5 — вище безглуздо, CPU з'їдає більше, ніж економить трафік;
• brotli on з brotli_static on — для попередньо стиснутих файлів (Brotli стискає на 20–30% краще за gzip);
• HTTP/2 з http2_max_concurrent_streams 128;
• fastcgi_cache для PHP-відповідей — кешування на рівні Nginx, минаючи PHP-FPM;
• worker_processes auto, worker_connections під кількість одночасних з'єднань.

PHP-FPM. Вибір між pm = dynamic і pm = static — не академічний:

• Static: фіксована кількість воркерів, без overhead на форк — для виділених серверів з передбачуваним навантаженням.
• Dynamic: економить RAM при низькому трафіку. pm.max_children рахуємо як (доступна RAM − RAM для MySQL/Redis) / середня витрата на процес.
• OPcache: opcache.memory_consumption=256, opcache.max_accelerated_files=20000, opcache.validate_timestamps=0 на продакшені (перезавантаження PHP-FPM при деплої).

MySQL/MariaDB. Головне вузьке місце майже завжди:

• slow_query_log з порогом 0.5 сек — кожен запит розбираємо через EXPLAIN.
• innodb_buffer_pool_size = 70–80% доступної RAM на виділеному сервері.
• Складені індекси для фасетного пошуку: (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) на b_iblock_element_property.
• OPTIMIZE TABLE b_iblock_element_property після масових операцій.

Як налаштувати кешування на три рівні?

Керований кеш компонентів. TTL налаштовуємо для кожного компонента окремо. Каталог — 3600 сек, новинна стрічка — 300 сек, банери — 86400. Однаковий TTL всюди — гарантія або застарілих даних, або марного кешу.

Композитний кеш. Технологія bitrix:composite — Nginx віддає готовий HTML із файлу, PHP не запускається. Динамічні зони (кошик, авторизація) підвантажуються AJAX-запитом через CBitrixComponent::setFrameMode(true). TTFB < 50 мс. Але не всі компоненти сумісні: $APPLICATION->ShowPanel() і прямий вивід через echo ламають композит. Перевіряємо кожну сторінку через панель «Продуктивність → Композитний сайт».

Порівняння: композитний кеш швидший за керований у 10–20 разів за часом першого байта. Офіційна документація Бітрікс з композитного кешу — Bitrix Composite.

Memcached / Redis. Переносимо кеш із файлової системи:

• Сесії → Redis (session.save_handler = redis) — швидше за файли в 10–50×, плюс робота в кластері.
• Кеш компонентів → Memcached через .settings.php: 'cache' => ['type' => 'memcache'].
• Кеш ORM-запитів — однакові GetList() не навантажують MySQL на кожному хіті.

Чому стандартних налаштувань MySQL недостатньо?

Індекси. Складені для фасетного пошуку. Покриваючі — для частих вибірок MySQL відповідає з індексу, не звертаючись до даних. Часткові індекси (MariaDB) для фільтрації за ACTIVE = 'Y'. Аудит невикористовуваних індексів — кожен сповільнює INSERT/UPDATE.

Партиціонування. Для таблиць з мільйонами рядків: b_stat_session, b_search_content_stem, Highload-блоки з історією. Партиція за датою — запит «замовлення за місяць» не сканує дані за три роки.

Реальний кейс: каталог 200 000 товарів, 50 властивостей. Фільтр за 10 властивостями займав 12 секунд. Після створення складених індексів за (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) та партиціонування b_iblock_element_property за IBLOCK_ID час виконання впав до 0,3 секунди. Навантаження на MySQL знизилося в 40 разів. Це дозволило скоротити витрати на сервер до 40% без втрати продуктивності.

Очищення. У будь-якій базі за рік-два накопичується: застарілий пошуковий індекс, прострочені записи в b_cache_tag, історія b_iblock_element_prop_s*, логи в b_event_log на гігабайти. Налаштовуємо регулярне очищення через агенти.

Партиціонування також вирішує проблему з паралельними запитами при обміні з 1С через CommerceML. Докладніше: MySQL Partitioning Documentation.

Після аудиту вашого проекту ми визначимо вузькі місця за 2 години та запропонуємо конкретний план прискорення. Замовте безкоштовний аудит швидкості — заповніть форму на сайті.

Фронтенд

Зображення — 60–80% ваги сторінки:

• WebP через CFile::ResizeImageGet() з BX_RESIZE_IMAGE_PROPORTIONAL + конвертація;
• srcset + sizes — не завантажуємо 3000px картинку в блок 400px;
• loading="lazy" для всього нижче першого екрану;
• AVIF — ще 20–30% економії порівняно з WebP.

CSS/JS:

• Вбудований модуль Бітрікс: об'єднання та мініфікація через «Налаштування → Оптимізація CSS/JS»;
• PurgeCSS / UnCSS — на типовому Бітрікс-проекті 60–70% CSS не використовуються;
• defer / async для некритичного JS;
• Critical CSS інлайном у <head> для миттєвого FCP.

Шрифти:

• <link rel="preload" as="font" crossorigin> для основного шрифту;
• font-display: swap — текст видно одразу;
• Subsetting через pyftsubset — вирізаємо кирилицю + латиницю, файл зменшується в 3–5 разів.

CDN

Cloudflare, BunnyCDN, AWS CloudFront або локальні (Selectel CDN, VK Cloud CDN).

• Статика (CSS, JS, зображення, шрифти) — через CDN.
• Правила кешування: Cache-Control: public, max-age=31536000, immutable для файлів з хешем.
• Оптимізація зображень на льоту (imgproxy, Cloudflare Polish) без навантаження на origin.

Навіщо потрібне навантажувальне тестування?

Не синтетичні бенчмарки, а реальні сценарії:

• k6 / wrk — імітація маршрутів: каталог → фільтрація → картка → кошик → оформлення.
• Метрики: RPS, час відповіді (p50, p95, p99), відсоток помилок.
• Xdebug (callgrind) або Blackfire — профілювання PHP, пошук вузьких місць.

Результат тестування — об'єктивна картина, де реально гальмує. Після оптимізації проганяємо повторно — фіксуємо покращення.

Результати

Що входить у роботу?

1. Аудит поточної продуктивності — аналіз slow-запитів, профілювання PHP, перевірка кешування, CDN, серверних налаштувань.
2. Налаштування серверної частини — Nginx, PHP-FPM, MySQL, Redis/Memcached, OPcache.
3. Оптимізація кешування — керований кеш, композитний сайт, налаштування TTL, теговане кешування.
4. Робота з БД — створення індексів, партиціонування, очищення, реорганізація EAV-таблиць.
5. Фронтенд — зображення (WebP/AVIF), CSS/JS (мініфікація, deferred), шрифти (preload, subsetting).
6. CDN — підключення, налаштування правил кешування.
7. Навантажувальне тестування — сценарії реальних користувачів, звіт за метриками.
8. Документація — опис усіх змін, рекомендації щодо подальшого обслуговування.
9. Гарантія — підтримка протягом 1 місяця після здачі.

Моніторинг

Без моніторингу через півроку все деградує. Новий модуль, неочищені логи, зміна в шаблоні — і швидкість повернулася до початкової.

• web-vitals API — Real User Monitoring від реальних відвідувачів.
• Synthetic monitoring — Pingdom, UptimeRobot, регулярні перевірки з різних локацій.
• Алерти — TTFB > 500 мс або LCP > 3 сек → сповіщення.

Терміни та вартість

Вартість розраховується індивідуально після аудиту. Отримайте консультацію щодо вашого проекту — оцінимо поточний стан і запропонуємо план прискорення з конкретними термінами та бюджетом. Ми — команда з 10+ роками досвіду в Бітрікс, виконали понад 200 проектів з оптимізації швидкості сайту. Замовте безкоштовний аудит швидкості — зв'яжіться з нами просто зараз.