Кэширование в облаке и на стороне сервера

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

Какие слои кэша есть в проекте

В типовом магазине на Битрикс кэш работает не в одном месте, а слоями. Понимание этой иерархии экономит часы диагностики, когда «изменения не появляются на сайте».

• Кэш компонентов — результат работы каждого компонента (список товаров, меню, детальная карточка) сохраняется в файлы или память.
• Управляемый кэш и теговый кэш — сущности ядра (CACHE_MANAGER, теги TaggedCache), которые сбрасываются точечно при изменении данных.
• Кэш HTML-страниц — композитный сайт и полное кэширование страниц (HTML Cache).
• Кэш PHP-акселератора — OPcache на уровне интерпретатора.
• Облачный кэш — CDN и обратный прокси перед сайтом.

Каждый слой ускоряет свой участок, но и «залипает» по-своему. Ниже — как настраивать и очищать каждый из них.

Где Битрикс хранит серверный кэш

По умолчанию Битрикс складывает кэш в файлы в каталоге /bitrix/cache/ и /bitrix/managed_cache/. Файловое хранилище простое и надёжное, но на нагруженном каталоге тысячи мелких файлов создают лишний I/O и медленную инвалидацию.

Тип хранилища задаётся в /bitrix/.settings.php в секции cache. Для магазинов под нагрузкой файловый кэш переносят в память:

Управляемый и теговый кэш

Обычный кэш компонента живёт фиксированное время жизни (TTL) и сбрасывается по таймеру. Это порождает дилемму: маленький TTL — частая пересборка и нагрузка, большой TTL — пользователь видит старую цену или остаток.

Управляемый кэш решает проблему: он сбрасывается не по времени, а по событию изменения данных. Компоненты каталога поддерживают его через параметр CACHE_TYPE = A (Авто) вместе с включённой опцией Учитывать теги в управляемом кэше.

Теговый кэш идёт дальше: при кэшировании компонент помечает результат тегами (например, iblock_id_15), а при изменении элемента инфоблока ядро сбрасывает только связанные записи. Включается в Настройки → Настройки продукта → Автокэширование и в настройках модуля main.

Автокэширование и режим разработки

Глобальный тумблер Автокэширование находится в Настройки → Настройки продукта → Автокэширование и на административной панели. Он включает кэш для всех компонентов, у которых стоит режим «Авто».

1. На боевом сайте автокэширование всегда включено.
2. На время разработки и отладки шаблонов его отключают, чтобы видеть изменения сразу.
3. После правок кэш очищают точечно, а не «сбрасывают всё» по привычке.

Полная очистка доступна на панели (Очистить файлы кэша → Весь кэш) и через API BXClearCache(true). На больших проектах массовый сброс лучше выполнять в часы низкой нагрузки: первый после сброса заход на страницу собирает её заново и нагружает базу.

HTML-кэш страниц и OPcache

Помимо кэша компонентов, Битрикс умеет кэшировать целые HTML-страницы. Технология «Композитный сайт» отдаёт статическую часть страницы мгновенно, а динамику (корзину, авторизацию) догружает через AJAX. Это верхний, самый быстрый слой серверного кэша.

Отдельно работает OPcache — акселератор PHP, который держит скомпилированный байт-код скриптов в памяти. Он не относится к данным сайта, но напрямую влияет на время генерации. Проверить его состояние можно в Настройки → Инструменты → Проверка системы и на странице bitrix/admin/php_command_line.php через phpinfo().

Кэширование в облаке через CDN

Облачный кэш — это слой перед вашим сервером: CDN или обратный прокси хранят копии ответов ближе к пользователю и отдают их, не дёргая origin. В Битрикс различают два сценария.

• Статика на CDN. Картинки, CSS, JS раздаются с узлов сети — это безопасно и включается штатным модулем clouds или сторонним CDN.
• Кэш HTML-страниц на CDN. Прокси кэширует и сами страницы. Это даёт максимальный эффект, но требует аккуратности: динамические страницы (корзина, личный кабинет, оформление заказа) нельзя кэшировать глобально.

Управление облачным кэшем идёт через HTTP-заголовки — Cache-Control, Expires, ETag. Для персональных страниц отдавайте Cache-Control: private, no-store, а для статики — длинный max-age с версионированием файлов.

Инвалидация: как не показать устаревшие данные

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

• Не включён теговый кэш — управляемый сброс по событию не срабатывает.
• Композит держит старый HTML — нужен сброс композитного кэша при обновлении контента.
• CDN отдаёт закэшированную страницу — требуется purge на стороне провайдера или короткий TTL.
• OPcache держит старый код — после деплоя не выполнен reset.

Рабочий принцип: сбрасывать точечно и по событию. В обмене с 1С (модуль sale/catalog) убедитесь, что после импорта отрабатывает инвалидация тегов инфоблока каталога, а не только запись в базу.

Итог

Кэш в Битрикс — это стек слоёв: компоненты, управляемый и теговый кэш, HTML-кэш и композит, OPcache и, наконец, облачный CDN. Ускорение даёт вся связка, но проблемы «старых данных» тоже приходят из неё — поэтому важнее всего правильная инвалидация: теговый кэш для каталога, аккуратные заголовки для CDN и reset OPcache при деплое.

Мы регулярно настраиваем эту связку под реальную нагрузку: переносим кэш в Redis, включаем теговую инвалидацию, разграничиваем композит и CDN, чтобы корзина и цены всегда были актуальными. Если каталог тормозит или пользователи видят устаревшие остатки — поможем разложить кэш по слоям и настроить его корректно.