Кэш Битрикса действительно ускоряет сайт, но именно из-за него правки, которые вы только что внесли в админке или в коде, могут не появиться на странице. Битрикс кэш работает сразу на нескольких уровнях, и каждый сбрасывается по-своему: где-то хватает кнопки в панели правки, где-то нужно лезть в файлы или перезапускать PHP-FPM. Ниже разбираю, из чего состоит кэш Битрикса, почему он иногда прячет свежие данные и как гарантированно сбросить именно тот уровень, который мешает.
Из каких уровней состоит кэш Битрикса
Когда клиент пишет «поменял текст, а на сайте всё старое», первым делом уточняю, о каком именно кэше речь, потому что в Битриксе их минимум пять, и они не связаны друг с другом напрямую:
- HTML-кэш (композитный режим) - готовая собранная страница, которая отдаётся гостю сайта без обращения к PHP и базе.
- Автокэширование компонентов - результат работы конкретного компонента (новости, каталог, меню), сохранённый в файлах.
- Управляемый кэш (тег-кэш) - данные, привязанные к тегам вроде инфоблока или раздела, которые сбрасываются автоматически при изменении этих данных.
- Opcache - кэш скомпилированного байт-кода PHP-файлов на уровне самого сервера, к Битриксу отношения не имеет, но влияет на то, видите вы новый код или старый.
- Кэш браузера и CDN - хранит статику (CSS, JS, картинки) на стороне пользователя или на edge-сервере, тоже никак не завязан на настройки Битрикса.
Путаница обычно в том, что человек сбрасывает один уровень (например, чистит кэш в админке) и не понимает, почему страница всё равно старая - а проблема в opcache после деплоя или в закэшированном браузером CSS.
| Уровень кэша | Где хранится | Что кэширует | Как сбросить |
|---|---|---|---|
| HTML-кэш (композит) | /bitrix/html_pages/ | Готовая HTML-страница для неавторизованного посетителя | Кнопка сброса в панели правки или удаление файлов вручную |
| Автокэширование компонентов | /bitrix/cache/ | Вывод конкретного компонента | Очистка в админке или истечение TTL |
| Управляемый кэш (тег-кэш) | /bitrix/managed_cache/ либо memcached/redis | Данные, привязанные к тегу (инфоблок, раздел) | Автоматически при изменении данных или вручную |
| Opcache PHP | Память процесса PHP-FPM | Скомпилированный байт-код PHP-файлов | Перезапуск PHP-FPM или вызов opcache_reset() |
| Кэш браузера и CDN | Браузер пользователя или edge-сервер CDN | Статика: CSS, JS, изображения | Cache-busting версией файла, очистка на стороне CDN |
Композитный кэш и почему гость видит старую версию страницы
Композитный режим - штатная возможность Битрикса, которая собирает страницу целиком в статический HTML и отдаёт его анонимным посетителям напрямую, без обращения к PHP. Файлы лежат в /bitrix/html_pages/, а решение, отдавать ли статическую версию, принимается ещё до инициализации ядра, по определённым правилам (наличие нужных cookie, метод запроса и так далее).
Отсюда классическая ситуация: администратор залогинен, правит текст, обновляет страницу и видит изменения сразу, потому что для авторизованного пользователя композит не работает. А обычный посетитель в этот момент продолжает получать статическую версию до истечения TTL или ручного сброса. Проверяю это просто - открываю страницу в режиме инкогнито без авторизации, там либо старая версия, либо уже актуальная.
Автокэширование компонентов и управляемый кэш
У каждого компонента в настройках есть параметр кэширования (тип «кэшировать всегда», «кэшировать, если нет прав на изменение» или «не кэшировать»), и время жизни в секундах. Здесь я обычно смотрю на то, как часто реально меняются данные: для меню и статичных блоков ставлю TTL побольше, для каталога с быстро меняющимися остатками - минуты, а не часы, иначе клиент ловит ситуацию, когда товар уже раскупили, а на сайте он «в наличии».
Управляемый кэш (тег-кэш) устроен умнее: результат привязывается к тегу, например, к конкретному инфоблоку, и когда через админку меняют элемент этого инфоблока, привязанный кэш сбрасывается сам, без ожидания TTL. Хранится он либо в файлах /bitrix/managed_cache/, либо, если на сервере поднят memcached или redis, там - это настраивается в разделе кэша конфигурации (.settings.php, параметр cache). На практике с интернет-магазинами часто вижу именно такую цепочку: цена в 1С поменялась, обмен прошёл, а на сайте старая цена, потому что кэш компонента корзины настроен как «кэшировать всегда» без привязки к тегам и живёт по TTL сутки.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Opcache и другие серверные кэши, о которых Битрикс не знает
Opcache - штука на уровне PHP, а не Битрикса: он держит в памяти процесса уже скомпилированный байт-код файлов, чтобы не парсить их заново на каждый запрос. Это ускоряет любой PHP-проект, но именно из-за него после деплоя новой версии кода на сайте иногда продолжает работать старая логика, хотя файлы на диске уже обновлены. Управляемый кэш и HTML-кэш тут ни при чём, их можно сбросить хоть десять раз - результат не изменится, пока не сброшен opcache.
Сбрасывается он либо перезапуском PHP-FPM (если есть доступ к серверу), либо вызовом функции opcache_reset() из скрипта, либо через панель хостинга, если провайдер даёт такую кнопку. На обычном виртуальном хостинге, где нет доступа к перезапуску сервисов, обычно ищу в панели управления пункт вроде «сброс кэша PHP» или дожидаюсь, пока файл обновится по времени модификации (у opcache есть проверка timestamp, но интервал проверки настраивается отдельно и по умолчанию может быть не мгновенным).
Отдельно стоит объектный кэш вроде memcached или redis, если он подключён как storage для управляемого кэша - это уже не файловая система, и «просто удалить папку /bitrix/cache/» тут не поможет, чистить нужно сам сервис.
Почему правки не видны: разбор типичных причин
Когда клиент пишет «ничего не поменялось», прохожу по списку в таком порядке, потому что так быстрее всего находится причина:
- Компонент, который выводит изменённый блок, закэширован с типом «кэшировать всегда» и TTL ещё не истёк - самая частая причина на инфоблоках и каталоге.
- Включён композитный режим, и правки видит только авторизованный администратор, а гостю отдаётся старая статическая страница из /bitrix/html_pages/.
- После деплоя кода не сброшен opcache, и сервер продолжает выполнять старый байт-код PHP-файла.
- Браузер или CDN отдают закэшированный CSS или JS по старому URL без версии файла - страница вроде обновилась, а стили и скрипты старые.
- Правка внесена не в том окружении: например, на тестовом сервере, а смотрят production, или наоборот.
Отдельно был случай на проекте с приёмом оплаты через Т‑Банк: клиент подключил новый способ доставки через СДЭК, но на странице оформления заказа калькулятор продолжал показывать старые тарифы. Причина оказалась в компоненте корзины с кэшированием на сутки без привязки к тегам - доставка считалась внутри компонента, а изменение настроек СДЭК тег не задевало, поэтому кэш не сбрасывался автоматически.
Как сбросить кэш Битрикса: 4 способа
1. Кнопка в админке
В разделе «Настройки» - «Настройки продукта» - «Автокэширование» есть кнопка очистки кэша, которая разом чистит файлы автокэширования и управляемого кэша. Это самый безопасный способ для тех, у кого нет доступа к серверу по FTP или SSH.
2. Удаление файлов вручную
Если доступ к файлам есть, можно напрямую удалить содержимое папок /bitrix/cache/, /bitrix/managed_cache/, /bitrix/html_pages/ и /bitrix/stack_cache/. Работает надёжно, но если на сайте высокая нагрузка, в момент удаления кэша возможен всплеск запросов к базе, пока кэш не наполнится заново.
3. Смена версии кэша (SID)
В .settings.php есть параметр cache с полем sid, а в админке в тех же настройках автокэширования - поле «Номер версии кэша». Если его поменять, все старые записи кэша считаются устаревшими сразу, без физического удаления файлов - удобно, когда нужно гарантированно сбросить кэш у всех посетителей одновременно, например, после массового обновления цен.
4. Сброс opcache отдельно от Битрикса
После деплоя кода одной очистки кэша Битрикса недостаточно - нужно ещё сбросить opcache, как описано выше. Забывают об этом чаще всего именно после обновления шаблона компонента или правки PHP-файла напрямую, а не через административные механизмы Битрикса.
Если разбираться с этим самостоятельно каждый раз некогда, обычно проще сразу отдать техподдержку сайта на Битриксе на аутсорс - тогда сброс кэша после каждого релиза или обновления цен становится не вашей головной болью.
Кэш сайта и кэш браузера или CDN - не путать
Даже если все уровни кэша Битрикса сброшены правильно, пользователь может продолжать видеть старую версию, потому что браузер закэшировал CSS или JS файл по прежнему URL. Решается это версионированием статики - добавлением параметра вроде ?v=2 или хеша содержимого к пути файла, тогда браузер воспринимает его как новый ресурс и загружает заново, а не берёт из своего кэша.
Если перед сайтом стоит CDN (например, для раздачи статики или всего сайта целиком), у него своя политика кэширования и свой TTL, никак не связанные с настройками Битрикса. Изменения на сервере CDN не видит, пока не истечёт его собственное время жизни кэша или пока кэш не сброшен вручную через панель управления CDN. На практике для сайтов с редкими деплоями это не проблема, а вот на проектах, где правки выкатываются по несколько раз в день, лишний уровень CDN-кэша иногда только мешает и требует отдельного скрипта инвалидации при каждом релизе.
1С-Битрикс регулярно обновляется, поэтому перед внедрением я сверяюсь с актуальной документацией.
Частые вопросы
Почему кэш Битрикса не сбрасывается кнопкой в админке
Чаще всего это значит, что проблема не в кэше Битрикса, а в opcache или в кэше браузера. Кнопка в админке чистит файлы автокэширования, управляемого кэша и композита, но не трогает байт-код PHP на сервере и статику в браузере пользователя - их нужно сбрасывать отдельно.
Нужно ли сбрасывать кэш после каждого обновления модуля
После обновления модулей и особенно после изменения шаблонов компонентов кэш лучше сбросить явно, потому что старая структура кэшированных данных может не совпадать с новой логикой вывода и вызвать визуальные ошибки на странице до истечения TTL.
Как понять, что включён именно композитный кэш
Простой способ - открыть страницу в режиме инкогнito без авторизации и сравнить с тем, что видно в панели правки под своей учётной записью. Если разница есть и она пропадает после сброса кэша в разделе «Настройки продукта» - «Автокэширование», значит дело в композите.
Можно ли просто отключить автокэширование, чтобы не разбираться с этим
Можно, но на нагруженном сайте это резко увеличит число запросов к базе данных на каждый визит, и страницы начнут открываться заметно медленнее. Правильнее настроить TTL и привязку к тегам под конкретные блоки сайта, чем отключать кэш целиком.