Настройка Cloudflare кеширования для 1С-Битрикс

Настройка Cloudflare кеширования для 1С-Битрикс

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

Почему стандартный Cloudflare-кеш не работает с Битрикс?

Cloudflare по умолчанию кеширует статику и HTML по простым правилам. Но Битрикс использует сессии и куки для персонализации: корзина, личный кабинет, избранное. Если кешировать HTML-страницу каталога без учёта состояния корзины, пользователи увидят чужие данные. Кроме того, админ-панель и API никогда не должны кешироваться. Поэтому нужны тонкие настройки Cache Rules и кеш-ключа.

Что кешируем на Cloudflare, что — нет

Как настроить 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.

Кеш-ключ и Vary

По умолчанию 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 условием выше)

Purge при изменении контента

Когда в Битрикс меняется товар или раздел, кеш 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 или полную очистку зоны.

Сравнение методов очистки кеша

Как убедиться, что кеш Cloudflare срабатывает?

Проверьте заголовок CF-Cache-Status в ответе сервера. Если статус HIT — страница отдаётся из кеша, сервер не нагружается. Если MISS или DYNAMIC — кеш не сработал, проверьте правила Cache Rules. Используйте curl с указанием куки, чтобы имитировать пользователя без корзины: curl -I -H "Cookie: " https://your-site.ru/catalog/. При правильной настройке вы увидите CF-Cache-Status: HIT и TTFB около 50 мс.

Польза от Edge Cache на практике

При правильной настройке страницы каталога отдаются из Cloudflare edge за 20–50 мс вместо 200–800 мс с сервера — в 5 раз быстрее. Нагрузка на PHP-FPM и базу данных при пиках трафика снижается в 5–20 раз, Cloudflare поглощает большую часть запросов. Экономия на серверных мощностях может быть существенной, а hit-rate кеша достигает 95%. Это позволяет выдерживать всплески посещаемости без дополнительных вложений.

Что входит в работу: пошаговый план

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

Сроки и стоимость

Базовая настройка занимает 3–5 дней, полный цикл с purge-интеграцией и мониторингом — 1–2 недели. Стоимость рассчитывается индивидуально после аудита. Свяжитесь с нами для точной оценки. Закажите консультацию — оценим проект и предложим решение под ваш бюджет.

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-запросов и заканчивается комплексной перестройкой инфраструктуры под ключ.

[Свяжитесь с нами для аудита] — мы определим узкие места за 2 часа и предложим конкретный план.

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

Nginx. Не просто «включили gzip». Конкретно:

• gzip_comp_level 4-5 — выше бессмысленно, CPU сжирает больше, чем экономит трафик;
• brotli on с brotli_static on — для предварительно сжатых файлов;
• 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 раз.

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

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

Фронтенд

Изображения — 60–80% веса страницы:

• WebP через CFile::ResizeImageGet() с BX_RESIZE_IMAGE_PROPORTIONAL + конвертация;
• srcset + sizes — не грузим 3000px картинку в блок 400px;
• loading="lazy" для всего ниже первого экрана;
• AVIF — ещё 20–30% экономии vs WebP (подробнее: 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 проектов по оптимизации скорости сайта.