Настройка кеширования в Битрикс: полное руководство

Главная / Блог / Кеширование Битрикс
13 марта 2026 · Время чтения: 6 мин

На протяжении 10 лет работы с Битрикс я убедился: правильная настройка кеширования — это 80% производительности сайта. Многие разработчики недооценивают эту тему, а зря — грамотное кеширование может ускорить сайт в 5-10 раз.

Что такое кеширование в Битрикс и зачем оно нужно

Кеширование в Битрикс — это механизм сохранения готовых данных для последующего быстрого доступа. Представьте: пользователь заходит на каталог товаров, система каждый раз обращается к базе данных, выполняет SQL-запросы, обрабатывает PHP-код. А с кешированием результат сохраняется в памяти или файлах, и следующий запрос отдаётся мгновенно.

Я часто встречаю сайты, где главная страница грузится 8-12 секунд. После настройки кеширования — 1-2 секунды. Разница колоссальная. У одного клиента был интернет-магазин на 50 000 товаров — без кеша страница каталога открывалась 15 секунд. После настройки — 0.8 секунды.

Битрикс поддерживает несколько типов кеширования:

💡
Совет: Всегда начинайте с базовых настроек кеширования. Сложные механизмы подключайте постепенно, контролируя производительность на каждом этапе.

Базовые настройки кеширования в админке

Первым делом идём в админку: «Настройки» → «Производительность» → «Кеширование». Здесь находятся основные переключатели. Я рекомендую включить:

Честно говоря, стандартные настройки Битрикс довольно консервативные. По умолчанию многое отключено, чтобы избежать проблем у новичков. Но на продакшене это нужно менять.

Особое внимание — настройке времени жизни кеша. По умолчанию стоит 3600 секунд (час). Для каталога товаров я ставлю 86400 (сутки), для новостей — 3600-7200 секунд. Главное правило: чем реже меняется контент, тем дольше может жить кеш.

У меня был проект — корпоративный портал на 500 сотрудников. Контент менялся редко, поэтому кеш компонентов поставил на неделю. Сайт летал, а нагрузка на сервер упала в разы.

⚠️
Важно: После включения кеширования обязательно проверьте все формы обратной связи, корзину, авторизацию. Агрессивное кеширование может сломать пользовательскую функциональность.

Настройка кеша компонентов

Кеш компонентов — это основа производительности Битрикс. Каждый компонент можно кешировать индивидуально с разными настройками. Я всегда настраиваю это вручную в шаблонах компонентов.

Базовые параметры кеширования компонента:

IncludeComponent(
    "bitrix:news.list",
    "my_template",
    array(
        // основные параметры компонента
        "IBLOCK_TYPE" => "news",
        "IBLOCK_ID" => "1",
        "NEWS_COUNT" => "10",
        
        // параметры кеширования
        "CACHE_TYPE" => "A", // A - автоматическое, Y - да, N - нет
        "CACHE_TIME" => "3600", // время жизни в секундах
        "CACHE_FILTER" => "Y", // кешировать с учётом фильтра
        "CACHE_GROUPS" => "Y", // кешировать с учётом групп пользователей
        "CACHE_NOTES" => "", // дополнительные заметки для кеша
    ),
    false, // компонент не является частью комплексного компонента
    array("HIDE_ICONS" => "Y") // дополнительные параметры
);?>

Самый важный параметр — CACHE_TYPE. Варианты:

На практике я почти всегда ставлю "A" и управляю кешированием глобально через админку. Так проще контролировать производительность всего сайта.

Особая тема — CACHE_GROUPS. Если на сайте есть разные группы пользователей с разным контентом, этот параметр обязателен. Иначе администратор увидит кеш обычного пользователя и наоборот.

Был случай: на корпоративном портале отключили CACHE_GROUPS, и все сотрудники видели административные разделы в меню. Пришлось срочно чистить кеш и пересматривать настройки.

Продвинутые настройки кеша компонентов

Для сложных компонентов я использую дополнительные параметры кеширования:

// Кеширование с дополнительными зависимостями
$APPLICATION->IncludeComponent(
    "bitrix:catalog.section",
    "catalog_list",
    array(
        "CACHE_TYPE" => "A",
        "CACHE_TIME" => "86400", // сутки для каталога
        "CACHE_FILTER" => "Y",
        "CACHE_GROUPS" => "Y",
        
        // уникальный ключ кеша для разных параметров
        "CACHE_NOTES" => $_GET['sort'].$_GET['order'],
        
        // очистка кеша при изменении элементов инфоблока
        "CACHE_TAGS" => array(
            "iblock_id_1", // очистится при изменении инфоблока
            "section_id_".$arResult["SECTION"]["ID"] // при изменении раздела
        )
    )
);

CACHE_NOTES — полезная штука для создания уникальных ключей кеша. Если каталог сортируется по цене или дате, для каждой сортировки нужен свой кеш.

Файловый кеш и OPcache

По умолчанию Битрикс сохраняет кеш в файловой системе в папке /bitrix/cache/. Это работает, но не оптимально. На высоконагруженных проектах файловый кеш становится узким местом — тысячи мелких файлов замедляют работу.

Я рекомендую настроить хранение кеша в памяти через Redis или Memcached. Но сначала про файловый кеш — его тоже можно оптимизировать.

Настройки в /bitrix/.settings.php:

 array(
        'value' => array(
            'type' => array(
                'class_name' => '\Bitrix\Main\Data\FileCache',
                'extension' => 'core',
                'required_file' => ''
            ),
            'sid' => $_SERVER["DOCUMENT_ROOT"]."#01", // уникальный идентификатор
            'ttl' => 2592000, // время жизни по умолчанию (30 дней)
            'read_only' => false,
        ),
        'readonly' => false,
    ),
    
    // настройки для тегированного кеша
    'cache_flags' => array(
        'value' => array(
            'config_options' => 3600,
            'site_domain' => 3600,
        ),
        'readonly' => false,
    )
);

Отдельная тема — PHP OPcache. Это не кеш Битрикс, а кеширование скомпилированного PHP-кода на уровне интерпретатора. Обязательно включайте в php.ini:

opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
opcache.save_comments=1
opcache.fast_shutdown=1

На продакшене ставлю validate_timestamps=0 — это отключает проверку времени изменения файлов и ускоряет работу. Но после обновления кода нужно очищать OPcache вручную.

ℹ️
Статистика: OPcache даёт прирост производительности 20-30% практически бесплатно. Это первое, что нужно настроить на любом PHP-сайте.

Redis и Memcached для кеширования

Для серьёзных проектов файловый кеш не подходит. Я использую Redis — быстро, надёжно, много возможностей. Memcached проще, но Redis функциональнее.

Установка Redis на Ubuntu/Debian:

sudo apt update
sudo apt install redis-server
sudo systemctl enable redis-server
sudo systemctl start redis-server

# проверяем работу
redis-cli ping
# должно вернуть PONG

Настройка Битрикс для работы с Redis в /bitrix/.settings.php:

 array(
        'value' => array(
            'type' => array(
                'class_name' => '\Bitrix\Main\Data\RedisCache',
                'extension' => 'redis',
                'required_file' => ''
            ),
            'redis' => array(
                'host' => '127.0.0.1',
                'port' => 6379,
                'database' => 0, // номер базы Redis (0-15)
                'password' => '', // если установлен пароль
            ),
            'sid' => $_SERVER["DOCUMENT_ROOT"]."#01",
            'ttl' => 2592000,
        ),
        'readonly' => false,
    ),
);

У меня был интернет-магазин с 500 000 товаров. На файловом кеше папка /bitrix/cache/ весила 8 ГБ, поиск файлов занимал секунды. После перехода на Redis — всё стало работать мгновенно.

Дополнительные настройки Redis в /etc/redis/redis.conf:

# максимальная память для кеша
maxmemory 2gb
maxmemory-policy allkeys-lru

# сохранение на диск отключаем для кеша
save ""

# оптимизация для производительности
tcp-keepalive 60
timeout 300

Главное преимущество Redis — скорость. Данные хранятся в памяти, доступ происходит за микросекунды. Плюс Redis умеет работать с тегированным кешем Битрикс — можно очищать связанные записи одной командой.

Мониторинг кеша Redis

Обязательно мониторьте использование Redis. Команды для диагностики:

# информация о Redis
redis-cli info

# использование памяти
redis-cli info memory

# количество ключей
redis-cli dbsize

# топ команд по времени выполнения
redis-cli --latency-history

На одном проекте заметил, что Redis жрёт всю память сервера. Оказалось, время жизни кеша стояло слишком большое, и старые записи не удалялись. Поправил настройки — всё нормализовалось.

Автокеширование и композитный сайт

Автокеширование в Битрикс — мощная штука, но капризная. Система автоматически кеширует HTML-код страниц целиком. Звучит здорово, но есть подводные камни.

Включается в админке: «Настройки» → «Производительность» → «Автокеширование». Основные параметры:

Главная проблема автокеширования — динамический контент. Корзина, авторизация, персональные данные — всё это ломается при агрессивном кешировании страниц.

Решение — композитный сайт. Это продвинутый режим, где статические части страницы кешируются, а динамические загружаются через AJAX. Настраивается сложно, но результат впечатляет.

⚠️
Осторожно: Композитный сайт требует доработки шаблонов. Все формы, корзина, авторизация должны работать через AJAX. Без опыта лучше не включать на продакшене.

Был проект — новостной портал с высокой посещаемостью. Включил автокеширование, и форма подписки перестала работать. Пришлось выносить её в отдельный компонент с отключенным кешированием.

Настройка исключений для автокеширования

Список страниц, которые нельзя кешировать:

Настройка исключений в /bitrix/.settings.php:

$arCacheExclude = array(
    "/personal/",
    "/cart/",
    "/order/",
    "/bitrix/",
    "/.git/",
    "/upload/",
    "/resize_cache/",
);

// исключения по регулярным выражениям
$arCacheExcludeRegex = array(
    "/\/personal\/.*/",
    "/.*\?.*PHPSESSID.*/",
    "/.*\?.*sessid.*/",
);

Кеш меню и включаемых областей

Меню и включаемые области — частые источники проблем с производительностью. Особенно многоуровневые меню на 100+ пунктов. Каждое обращение к меню без кеша — это десятки SQL-запросов.

Кеширование меню настраивается в компоненте bitrix:menu:

IncludeComponent(
    "bitrix:menu",
    "horizontal_multilevel",
    array(
        "ROOT_MENU_TYPE" => "top",
        "MAX_LEVEL" => "3",
        "CHILD_MENU_TYPE" => "left",
        
        // кеширование меню
        "CACHE_TYPE" => "A",
        "CACHE_TIME" => "86400", // сутки - меню меняется редко
        "CACHE_NOTES" => "",
        "CACHE_SELECTED_ITEMS" => "Y", // кешировать активные пункты
    ),
    false
);?>

Особенность кеша меню — он привязан к текущей странице. Для каждой страницы свой кеш с подсвеченными активными пунктами. CACHE_SELECTED_ITEMS=Y обязательно включать.

Включаемые области кешируются автоматически, если включено общее кеширование. Но можно настроить индивидуально через SetPageProperty:

SetPageProperty("CACHE_TYPE", "N");
include($_SERVER["DOCUMENT_ROOT"]."/include/header_banner.php");

// или наоборот, принудительно включить с большим временем
$APPLICATION->SetPageProperty("CACHE_TYPE", "Y");
$APPLICATION->SetPageProperty("CACHE_TIME", "604800"); // неделя
include($_SERVER["DOCUMENT_ROOT"]."/include/footer_contacts.php");
?>

На одном корпоративном сайте было меню на 500 пунктов — структура компании со всеми отделами. Без кеша страница грузилась 5 секунд только из-за меню. После включения кеширования — 0.3 секунды.

Тегированный кеш

Тегированный кеш — это умная система очистки связанных данных. Представьте: изменили товар в каталоге, нужно очистить кеш этого товара, списка товаров раздела, главной страницы с хитами продаж. Вручную это делать нереально.

Тегированный кеш решает проблему автоматически. Каждая запись кеша помечается тегами, при изменении данных очищаются все записи с соответствующими тегами.

Включается в настройках производительности, но требует доработки компонентов. Пример для каталога товаров:

getTaggedCache()->registerTag($arCacheTags);
}
?>

При изменении товара система автоматически найдёт все записи кеша с тегом "element_id_123" и очистит их. Магия!

На практике тегированный кеш настраиваю не сразу. Сначала базовое кеширование, потом, когда сайт растёт и появляются проблемы с актуальностью данных, добавляю теги.

Был интернет-магазин с частыми обновлениями цен. Менеджеры меняли цены, а на сайте старые висели часами. Тегированный кеш решил проблему — цены обновляются мгновенно, но производительность не страдает.

Настройка nginx для кеширования

Кеширование на уровне веб-сервера — последний рубеж оптимизации. Nginx может отдавать статический контент напрямую, не обращаясь к PHP. Для Битрикс это особенно актуально — много статических файлов, изображений, CSS, JS.

Базовая конфигурация nginx для Битрикс:

server {
    listen 80;
    server_name example.com;
    root /var/www/example.com;
    index index.php index.html;

    # кеширование статических файлов
    location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff|woff2|ttf|svg)$ {
        expires 30d;
        add_header Cache-Control "public, immutable";
        add_header Vary Accept-Encoding;
        
        # сжатие на лету
        gzip on;
        gzip_vary on;
        gzip_types text/css application/javascript image/svg+xml;
    }

    # кеширование для upload папки
    location /upload/ {
        expires 7d;
        add_header Cache-Control "public";
        
        # защита от исполнения PHP в upload
        location ~* \.php$ {
            deny all;
        }
    }

    # кеширование resize_cache
    location /resize_cache/ {
        expires 30d;
        add_header Cache-Control "public, immutable";
    }

    # основная обработка PHP
    location / {
        try_files $uri $uri/ @bitrix;
    }

    location @bitrix {
        fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root/bitrix/urlrewrite.php;
        include fastcgi_params;
        
        # отключаем кеширование для динамических страниц
        add_header Cache-Control "no-cache, must-revalidate";
    }
}

Ключевые моменты конфигурации:

На одном проекте после настройки nginx кеширования размер передаваемых данных уменьшился на 60%. CSS и JS файлы стали загружаться из браузерного кеша, а не с сервера.

💡
Совет: Используйте версионность для статических файлов. Добавляйте ?v=91 к CSS/JS при обновлении, чтобы браузеры загрузили новые версии.

Продвинутое кеширование в nginx

Для высоконагруженных сайтов можно настроить кеширование PHP-ответов в nginx:

# в блоке http
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=bitrix:10m max_size=1g 
                 inactive=60m use_temp_path=off;

server {
    # кеширование для анонимных пользователей
    location / {
        # не кешируем POST запросы и авторизованных пользователей
        if ($request_method = POST) {
            set $no_cache 1;
        }
        if ($http_cookie ~* "BITRIX_SM_|PHPSESSID") {
            set $no_cache 1;
        }
        
        proxy_cache bitrix;
        proxy_cache_bypass $no_cache;
        proxy_no_cache $no_cache;
        proxy_cache_valid 200 10m;
        proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
        
        proxy_pass http://127.0.0.1:8080; # бэкенд с PHP
    }
}

Это сложная настройка, требует отдельного PHP-бэкенда на другом порту. Но даёт фантастическую производительность — nginx отдаёт кешированные страницы без обращения к PHP.

Оптимизация и мониторинг кеша

Кеширование — не поставил и забыл. Нужен постоянный мониторинг и оптимизация. Я использую несколько инструментов для контроля производительности кеша.

Встроенная статистика Битрикс доступна в админке: «Настройки» → «Производительность» → «Тест производительности». Здесь видно:

Для детального анализа добавляю в шаблон сайта код мониторинга:


if ($_GET['debug'] == 'performance') {
    $endTime = microtime(true);
    $endMemory = memory_get_usage();
    
    echo "";
}
?>

Полезные команды для мониторинга Redis:

# статистика кеша
redis-cli info stats

# топ команд
redis-cli info commandstats

# мониторинг в реальном времени
redis-cli monitor

# очистка всего кеша (осторожно!)
redis-cli flushall

На продакшене обязательно настраиваю алерты на использование памяти Redis. Если память заканчивается, кеш начинает вытеснять нужные данные, производительность падает.

Проблемы и их решения

Типичные проблемы с кешированием Битрикс:

1. Кеш не очищается при изменении контента
Решение: проверить настройки тегированного кеша, добавить принудительную очистку в обработчиках событий.

2. Разный контент для разных групп пользователей
Решение: включить CACHE_GROUPS="Y" во всех компонентах.

3. Формы перестали работать после включения автокеширования
Решение: вынести формы в отдельные компоненты с отключенным кешированием или использовать AJAX.

4. Кеш жрёт всю память сервера
Решение: настроить maxmemory в Redis, уменьшить время жизни кеша, добавить ротацию старых записей.

Был случай на крупном портале: включили агрессивное кеширование, и пользователи стали видеть чужие персональные данные. Оказалось, забыли про CACHE_GROUPS в компоненте личного кабинета. Пришлось срочно отключать кеширование и чистить все записи.

Кеширование в Битрикс — мощный инструмент, но требует понимания и осторожности. Начинайте с простого, постепенно усложняйте, всегда тестируйте на тестовом сайте перед продакшеном. Правильно настроенный кеш может ускорить сайт в разы, но неправильно настроенный — сломать функциональность.

И помните: медленная работа сайта — это не всегда проблема кеширования. Иногда дело в плохих SQL-запросах, неоптимизированных изображениях или проблемах с хостингом. Кеширование решает проблемы производительности, но не маскирует архитектурные ошибки.

Если у вас возникли сложности с настройкой кеширования или нужна помощь в оптимизации Битрикс-сайта, обращайтесь за профессиональной поддержкой Битрикс. Правильная настройка кеширования требует опыта и знания всех подводных камней системы.

Нужна помощь с оптимизацией вашего Битрикс-сайта?

Наши эксперты помогут настроить кеширование и ускорить работу вашего сайта в несколько раз.

П
Павел
Веб-разработчик · 10+ лет опыта · Bitrix, WordPress, Laravel

Читайте также

Сколько стоит поддержка сайта в 2026 году → Как выбрать хостинг для сайта: на что обратить внимание → Как защитить сайт от взлома: 10 правил безопасности →