Кеш в Битрикс: что проверить до первой настройки

В 1С-Битрикс кеш может сократить время ответа страницы, но тот же механизм способен показать покупателю старую цену, не вывести изменённый остаток или скрыть результат правки шаблона. Этот материал ориентирован на 1С-Битрикс: Управление сайтом 24.x; названия пунктов в более новых версиях могут отличаться. За 20–40 минут вы проверите окружение, разберёте виды кеша и подготовите безопасный порядок очистки перед публикацией изменений.

Что нужно иметь до начала

• Доступ администратора к панели «Настройки» и разделам, связанным с производительностью.
• Доступ к файловой системе сайта или панели хостинга, если потребуется проверить права на каталоги кеша.
• Тестовую страницу, где видны динамические данные: цена, остаток, авторизованный пользователь или список товаров.
• Понимание, где находится рабочий сайт, а где тестовый. Очистка кеша на продакшене может временно увеличить нагрузку.
• Резервную копию файлов и базы перед изменением настроек, особенно если вы одновременно обновляете ядро или компоненты.

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

Какие виды кеша есть в Битрикс

Кеш компонентов

Компонент получает данные, формирует HTML и сохраняет результат на заданный срок. При следующем запросе Битрикс может отдать сохранённый результат, не выполняя заново запросы к базе и расчёты компонента.

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

Управляемый кеш

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

Кеш HTML-страниц

Полный кеш страницы отдаёт готовый HTML ещё до выполнения большей части PHP-кода. Это самый быстрый вариант для одинакового публичного контента, но он плохо сочетается с персонализацией, корзиной, избранным и блоками, зависящими от авторизации.

Кеш в PHP и инфраструктуре

Отдельно работают OPcache, кеширование на уровне веб-сервера, CDN и прокси. Они не заменяют кеш Битрикс. Если браузер или CDN держит старый файл, очистка кеша компонентов не изменит результат для посетителя.

¹ Инвалидация кеша — удаление или пометка устаревшими сохранённых данных после изменения источника. В Битрикс она может происходить по сроку хранения, при изменении сущности или вручную.

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

Пошаговая подготовка кеша

1. Зафиксируйте проблему без очистки кеша. Откройте страницу в обычном браузере и в приватном окне, сравните результат для гостя и авторизованного пользователя. Если различия есть только в одном браузере, проверьте браузерный кеш и CDN. Проверка пройдена, если вы понимаете, какой слой отдаёт устаревший результат.
2. Проверьте дату и окружение. Убедитесь, что сервер использует поддерживаемую версию PHP для вашей редакции и версии Битрикс, а системное время сервера корректно. Срок жизни кеша считается по времени сервера. Проверка пройдена, если время в панели, PHP и операционной системе не расходится на часы.
3. Разделите блоки на статичные и персональные. Логотип, меню и список категорий обычно можно кешировать надолго. Корзину, имя пользователя, персональные цены и остатки нельзя бездумно включать в общий кеш страницы. Проверка пройдена, если для каждого блока записано, может ли его HTML быть одинаковым для двух разных посетителей.
4. Проверьте настройки компонента. Найдите компонент, который выводит проблемный блок, и посмотрите режим кеширования, время хранения и зависимость от групп пользователей. Не меняйте сразу несколько параметров. Проверка пройдена, если вы знаете, какой компонент создаёт кеш и где находится его настройка.
5. Измените один параметр на тестовой копии. Для проверки поставьте короткий срок только на нужном компоненте, сохраните настройки и откройте страницу с принудительным обновлением. Не используйте короткий срок как постоянное лечение: он увеличивает число обращений к базе. Проверка пройдена, если после изменения вы видите новый контент, а в логах и профилировщике нет резкого роста запросов.
6. Очистите кеш штатным способом. В административной панели используйте раздел очистки кеша, а не удаление произвольных каталогов. После очистки первый запрос обычно формирует данные заново и может быть медленнее. Проверка пройдена, если новая версия страницы появляется после одного-двух обновлений, а затем время ответа возвращается к обычному.
7. Проверьте изменение через пользовательский сценарий. Измените тестовую цену или текст, выйдите из аккаунта, откройте страницу в приватном окне и проверьте карточку, каталог и корзину. Проверка пройдена, если гостевой и авторизованный сценарии показывают допустимые для них данные.

Частые ошибки новичков

«На сайте старая версия шаблона»

Причина может быть в кеше компонента, HTML-кеше, CDN или браузере. Очистите слои по одному и после каждого действия проверяйте страницу в приватном окне. Если меняется только CSS или JavaScript, проверьте версию файла и настройки браузерного кеширования, а не только кеш Битрикс.

«Изменил элемент, но список не обновился»

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

«После очистки сайт стал медленным»

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

«Персональные данные видны не тому пользователю»

Остановите публикацию и отключите общий кеш для проблемного блока или страницы. Проверьте, не попал ли пользовательский HTML в общий кеш, CDN или серверный прокси. До исправления не пытайтесь лечить ситуацию только сокращением времени жизни: даже короткое окно может быть критичным.

Что проверить перед публикацией

• Цена и остаток меняются после обновления источника.
• Гость не получает блоки авторизованного пользователя.
• Корзина и избранное не берутся из общего кеша страницы.
• Изменение элемента через административную панель обновляет связанные списки.
• Первый запрос после очистки не создаёт длительную очередь и не перегружает базу.
• Внешний CDN, прокси и браузер не удерживают старую версию критичных данных.

Где кеш ломается

Самая опасная граница — смешение публичного и персонального HTML. Один и тот же шаблон может содержать меню для всех и имя пользователя для конкретного аккаунта. Если кешируется весь результат без разделения, Битрикс не угадает, какую часть можно безопасно отдавать повторно.

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

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

Что делать дальше

После базовой проверки соберите замеры для трёх сценариев: первый запрос после очистки, повторный запрос из кеша и запрос для авторизованного пользователя. Запишите время ответа, количество SQL-запросов, потребление памяти и долю ответов с ошибками. На продакшене наблюдайте не только среднее время, но и p95: редкие медленные запросы часто появляются именно во время прогрева.

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