Когда кеш мешает, а когда без него никак
К разработчикам сайтов на 1С-Битрикс приходят с двумя противоположными жалобами. Первая: «после обмена с учётной системой на сайте висят старые цены», «в корзине у клиента показывается чужое количество товаров», «поменяли баннер, а посетители видят прежний». Вторая: «сайт открывается по четыре секунды, хостинг просит перейти на тариф дороже». Нередко это один и тот же сайт до и после того, как кто-то в сердцах выключил кеширование.
Кеш в 1С-Битрикс устроен так, что обе проблемы решаются одновременно. Страницы быстро отдаются из сохранённой копии, а данные, которые должны меняться, обновляются вовремя. Для этого нужно понимать, какой вид кеша за что отвечает, и настраивать его под характер данных, а не одной кнопкой на весь сайт.
Какие виды кеша есть в 1С-Битрикс
В учебном курсе разработчика Bitrix Framework описано несколько механизмов, и путают их постоянно.
Автокеширование компонентов включается одной кнопкой в административной части. После этого стандартные компоненты сохраняют результат своей работы и при повторных обращениях не ходят в базу данных, пока кеш не истечёт или не будет сброшен.
Неуправляемый кеш разработчик сам ставит на ресурсоёмкие участки своего кода. Результат складывается в файлы в каталоге /bitrix/cache/ и живёт заданное время. При изменении исходных данных такой кеш сам не пересчитывается. Документация отдельно предупреждает: при неправильном применении папка кеша сильно разрастается.
Управляемый кеш обновляется автоматически, когда меняются данные, из которых он собран. Частный и самый полезный его вариант называется тегированным кешем, о нём ниже.
Кеш меню тоже управляемый. Он обновляется, когда меню редактируют или меняют права доступа.
HTML-кеш документация называет устаревшей технологией и советует вместо него переходить на «Композитный сайт». Композит сохраняет готовый HTML страницы целиком, а персональные части подгружает отдельно.
На большинстве сайтов основную работу делает связка из автокеширования компонентов и тегированного кеша, композит добавляют сверху, когда базовый кеш уже настроен правильно. Неуправляемый кеш в собственном коде требует отдельной проверки, потому что именно он чаще всего показывает посетителям устаревшие данные.
Автокеширование и параметры компонента
Глобальные настройки находятся на странице «Автокеширование» в административном разделе. На вкладке «Кеширование компонентов» есть кнопка, которая включает и выключает автокеширование для всего сайта. Документация советует выключать его на время разработки, чтобы правки сразу были видны, и обязательно включать перед запуском. Там же настраивается управляемый кеш.
У каждого компонента в диалоге параметров есть три настройки, от которых зависит поведение кеша.
«Тип кеширования» принимает значения «Авто + Управляемое», «Кешировать» и «Не кешировать». Первый вариант подчиняется глобальной кнопке автокеширования. «Кешировать» включает кеш у компонента независимо от глобальной настройки. «Не кешировать» выключает его совсем, и такое значение оправдано только там, где данные обязаны быть актуальными на каждом хите и других способов обеспечить это нет.
«Время кеширования» задаётся в секундах. Сколько ставить, зависит от того, умеет ли компонент работать с тегированным кешем. Если умеет и тегированный кеш включён, время можно делать большим, данные всё равно сбросятся при изменении. Если нет, время приходится подбирать под частоту обновления данных.
«Учитывать права доступа» делает кеш разным для разных групп пользователей. Эта галочка напрямую связана с динамикой. Когда оптовики видят одни цены, а розничные покупатели другие, или часть разделов открыта только авторизованным клиентам, без неё компонент закеширует вариант для первой пришедшей группы и покажет его всем остальным. У B2B-сайтов с личными кабинетами это одна из самых частых причин жалоб «клиент видит не свою цену».
Тегированный кеш: данные обновляются сами
Тегированный кеш позволяет не ждать, пока сохранённая копия устареет по времени. Файлы кеша помечаются тегами, и при изменении данных система сбрасывает всё, что помечено соответствующим тегом. Для инфоблоков стандартный тег строится как iblock_id_ плюс номер инфоблока. При добавлении элемента регистрируется ещё тег iblock_id_new.
Включается механизм константой BX_COMP_MANAGED_CACHE в файле dbconn.php или через административный интерфейс, на той же странице автокеширования. Дальше стандартные методы добавления, изменения и удаления элементов и разделов инфоблока сами сбрасывают связанный кеш. Поменял контент-менеджер цену в админке, и компонент каталога при следующем обращении пересоберёт данные.
У механизма есть серьёзное ограничение. В документации прямо сказано, что для часто обновляемого большого массива данных тегированный кеш использовать не оправданно: регистрация тегов в базе сама создаёт нагрузку. На практике это задевает интернет-магазины, у которых обмен с учётной системой каждые несколько минут меняет тысячи товаров. Каждое изменение сбрасывает кеш инфоблока, и сайт почти всё время работает на пустом кеше.
Собственный код разработчика тоже может работать с тегами. Для этого при создании кеша регистрируют нужный тег через $CACHE_MANAGER, а для принудительного сброса вызывают $CACHE_MANAGER->ClearByTag() или CIBlock::clearIblockTagCache() с номером инфоблока. Если подрядчик написал свой компонент на неуправляемом кеше и теги не зарегистрировал, стандартная очистка его не затронет. Это частый источник историй вида «в админке цена новая, а на сайте старая уже третий час».
Где динамика ломается чаще всего
На поддержке сайтов на 1С-Битрикс динамика чаще всего ломается в одних и тех же местах, и проверять стоит именно их.
Цены и остатки после обмена
Если обмен идёт редко, тегированный кеш справляется. Если часто и большими пакетами, выбирайте между двумя подходами. Можно оставить короткое время кеширования у компонентов каталога и отказаться от тегов для этого инфоблока. А можно вынести остатки и цену в отдельный лёгкий запрос, который не кешируется, а тяжёлую карточку товара закешировать надолго. Второй вариант сложнее в разработке, но под нагрузкой ведёт себя лучше.
Персональные данные
Имя авторизованного пользователя, счётчик корзины, избранное, выбранный город. Всё, что зависит от конкретного посетителя, в общий кеш попадать не должно. Иначе первый посетитель «заражает» сохранённую копию своими данными, и её получают все следующие.
Разные цены для групп
Про галочку «Учитывать права доступа» уже сказано выше. Её стоит проверить у каждого компонента, который выводит цены, скидки или закрытые разделы, включая компоненты в шапке и боковых колонках.
Собственный код
Самописные компоненты, обработчики и вставки в шаблоне. Посмотрите, где разработчик использовал неуправляемый кеш, какое время жизни поставил и зарегистрировал ли теги. Слишком долгий неуправляемый кеш на данных, которые меняются, почти гарантирует жалобы.
Формы и всё, что связано с сессией
Данные сессии, случайные идентификаторы и проверочные значения форм тоже относятся к персональному содержимому. Если они оказались внутри закешированного шаблона, форма может перестать отправляться у части посетителей, и такую ошибку долго не замечают: у сотрудника, который проверяет форму сам один раз, она обычно отправляется без проблем.
Композитный сайт: скорость без чужой корзины
Композит сохраняет готовый HTML страницы и отдаёт его сразу. Части, которые должны быть персональными или свежими, оформляются как динамические области. При загрузке из кеша на их месте сначала стоит заглушка, а актуальное содержимое приходит фоновым запросом.
Решение о том, можно ли кешировать страницу, принимается голосованием компонентов. Каждый компонент голосует за композит или против, и если против проголосовал хотя бы один, страница в композитный кеш не попадает. Метод setFrameMode() позволяет компоненту участвовать в композите, а собственные динамические области разработчик создаёт через createFrame().
В официальном блоге разработчиков 1С-Битрикс перечислены типичные причины, по которым композитный кеш постоянно перезаписывается. Среди них случайные идентификаторы в разметке, данные из сессии и содержимое, зависящее от User Agent браузера. Счётчик корзины и имя пользователя там советуют держать в динамических областях или в localStorage. Ещё один совет оттуда: после изменения вёрстки очищать весь композитный кеш.
У динамических областей есть заметный посетителю побочный эффект. Сначала на месте области видна заглушка, потом её сменяет актуальное содержимое, и элемент «мигает». В том же блоге предлагают подставлять данные из localStorage ещё до отрисовки, тогда счётчик корзины не прыгает с нуля на реальное число. Для сайта, где шапка с корзиной видна на каждой странице, эту деталь лучше заложить сразу.
Подробнее о подготовке сервера и включении режима мы писали в статье «Композитный сайт на 1С-Битрикс: как ускорить загрузку страниц». Учтите, что ошибки базового кеша компонентов композит не исправляет. Если компонент под композитом отдаёт устаревшую цену, композит просто быстрее покажет её посетителю.
Порядок настройки на действующем сайте
На работающем сайте кеш настраивают по шагам и начинают с тестовой копии.
Сначала составьте опись. Какие компоненты стоят на ключевых страницах (главная, каталог, карточка товара, корзина, личный кабинет), какой у каждого тип и время кеширования, где есть собственный код с кешем. Для этого подойдёт обычная таблица, заполненная по режиму правки сайта и исходникам шаблона.
Затем разложите данные по характеру изменений. Удобно пользоваться такой схемой:
| Данные | Как меняются | Что обычно подходит |
|---|---|---|
| Статьи, новости, страницы услуг | редко, вручную | автокеширование с тегированным кешем, долгое время |
| Меню | редко | стандартный управляемый кеш меню |
| Каталог без частого обмена | несколько раз в день | тегированный кеш инфоблока |
| Цены и остатки с частым обменом | каждые несколько минут | короткое время кеша или отдельный некешируемый запрос |
| Цены для групп, закрытые разделы | зависят от посетителя | учёт прав доступа в параметрах компонента |
| Корзина, имя, избранное | у каждого своё | вне общего кеша, динамические области композита |
Тестовая копия должна быть похожа на боевой сайт по объёму данных. На каталоге из двухсот товаров проблемы частого обмена и тегированного кеша просто не проявятся, и настройка, которая выглядела идеальной, сломается в первый же день после переноса.
После этого включите автокеширование и управляемый кеш, выставьте параметры компонентов по схеме и прогоните сценарии проверки. Композит подключайте последним, когда предыдущий шаг работает без ошибок.
Сценарии проверки лучше записать заранее и проходить под разными ролями: анонимный посетитель, авторизованный розничный клиент, оптовый клиент, контент-менеджер. Для каждой роли проверьте цену и наличие в карточке, счётчик корзины, отправку форм, отображение закрытых разделов. Отдельно проверьте, как быстро на сайте появляется изменение цены, сделанное в админке и пришедшее через обмен. Проходить сценарии нужно в обычном браузере без авторизации в админке, иначе вы увидите сайт не так, как его видят клиенты.
Очистка кеша: когда и как
Сбросить кеш вручную можно несколькими способами. На панели управления страницей есть кнопка «Сбросить кеш» с пунктами «Обновить кеш компонентов» (сбрасывает только компоненты) и «Обновить кеш страницы» (очищает весь кеш страницы). В режиме правки кеш отдельного компонента обновляется через его панель. Кроме того, кеш сбрасывается сам по истечении времени кеширования, а управляемый ещё и при изменении данных.
Ручная очистка удобна, чтобы проверить гипотезу: если после сброса кеша компонента цена на странице стала правильной, проблема именно в его кеше, а не в данных. Но как постоянное решение она не работает. Если контент-менеджер после каждой правки идёт нажимать «Сбросить кеш», значит, у компонента не настроен управляемый кеш или код не регистрирует теги.
С полной очисткой кеша на большом сайте стоит быть аккуратнее. После неё все страницы и компоненты собираются заново при первых обращениях, и в часы пик это даёт заметный всплеск нагрузки на базу. Плановую полную очистку, например после выкладки нового шаблона, удобнее делать тогда, когда посетителей меньше всего.
Отдельно следите за размером каталога /bitrix/cache/. Документация предупреждает, что неправильно использованный неуправляемый кеш раздувает эту папку. Если она растёт неделями без остановки, где-то в коде кеш создаётся с ключом, который почти не повторяется, и сохранённые копии никогда не используются повторно.
Пример: интернет-магазин с частым обменом
Пример условный, собран из типичных ситуаций на поддержке. Магазин стройматериалов, около двадцати тысяч товаров, обмен с учётной системой каждые пятнадцать минут, две группы покупателей с разными ценами. Жалоб две: страницы каталога грузятся медленно, а оптовики время от времени видят розничную цену.
Опись показала три проблемы. У компонента списка товаров не стояла галочка учёта прав доступа, поэтому в кеш попадал вариант для той группы, которая открыла раздел первой. Тегированный кеш каталога сбрасывался при каждом обмене, и между обменами он почти не успевал наполниться. А блок «Хиты продаж» на главной был написан на неуправляемом кеше со временем жизни в сутки, поэтому показывал товары, которых уже не было в наличии.
Исправление заняло несколько итераций на тестовой копии. У компонентов с ценами включили учёт прав доступа. Остатки и цену в карточке и списке вынесли в лёгкий отдельный запрос, а тяжёлую часть карточки (описание, характеристики, фото) закешировали надолго. Блок хитов перевели на теги инфоблока. Композит включили последним, с динамическими областями для корзины, имени пользователя и цены.
В подобных проектах результат проверяют по двум вещам: время ответа сервера на страницах каталога и отсутствие жалоб на чужие цены и устаревшие остатки. Цифры ускорения сильно зависят от сервера, шаблона и объёма каталога, поэтому обещать их до аудита было бы нечестно.
Как понять, что кеш настроен правильно
Проверка складывается из технических показателей и поведения сайта. С технической стороны смотрите на время ответа сервера на повторных запросах, количество SQL-запросов на страницу, размер каталога /bitrix/cache/ и то, не растёт ли он без остановки. В 1С-Битрикс для этого есть модуль «Монитор производительности», он собирает статистику по страницам и SQL-запросам. Про его метрики мы подробно писали в статье о мониторинге производительности, и для сайта логика та же.
С точки зрения бизнеса признаков два. Изменение цены или наличия появляется на сайте за понятное и предсказуемое время. Клиенты разных групп видят свои данные, а корзина и личный кабинет у каждого свои. Если хотя бы один из признаков не выполняется, настройку нужно доводить, даже когда по скорости всё хорошо: оптовик, который увидел розничную цену, может уйти к конкуренту раньше, чем вы узнаете об ошибке.
Если на вашем сайте кеш то выключают, то включают обратно, а жалобы не прекращаются, начните с описи компонентов и собственного кода: обычно проблему видно уже на этом шаге. Когда своими силами разобраться не получается, настройку кеша, композита и доработку компонентов под частый обмен можно заказать у нас в рамках разработки и поддержки сайтов на 1С-Битрикс.
Частые вопросы
Можно ли просто выключить кеш, чтобы данные всегда были свежими?
Технически можно, но на сайте с каталогом это обычно заметно замедляет страницы и повышает нагрузку на сервер. Правильнее найти компоненты, которые показывают устаревшие данные, и настроить у них тип кеша, время жизни, учёт прав доступа и теги.
Чем кеширование компонентов отличается от композитного сайта?
Кеш компонентов сохраняет результат работы отдельных блоков и избавляет их от лишних запросов к базе. Композитный сайт сохраняет HTML страницы целиком и отдаёт его сразу, а персональные части подгружает через динамические области. Композит работает поверх кеша компонентов и не заменяет его.
Какое время кеширования ставить компонентам?
Если компонент поддерживает тегированный кеш и он включён, время можно делать большим: при изменении данных кеш сбросится сам. Для компонентов без тегов и для данных, которые обновляются обменом, время подбирают под частоту обновления.
Почему после обмена с учётной системой на сайте старые цены?
Самые частые причины: неуправляемый кеш в собственном коде без тегов, слишком долгое время кеширования у компонента без поддержки тегов или выключенный управляемый кеш. Реже причина в том, что цена выводится из другого источника, чем тот, который обновляет обмен.
Нужно ли чистить кеш после изменения шаблона сайта?
Да. Для композитного режима разработчики 1С-Битрикс прямо советуют очищать весь композитный кеш после изменения вёрстки, иначе часть посетителей какое-то время будет получать страницы со старой разметкой.