Композитный кеш Битрикс: настройка, матрица кеширования и проверка

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

Задача бизнеса и границы решения

Любая CMS собирает HTML-код страницы из программного кода: сервер выполняет запросы к базе, собирает шаблон, подставляет данные и только потом отдаёт готовый документ браузеру. Чем сложнее страница, тем дольше идёт сборка, и тем заметнее задержка для посетителя. Композитный кеш решает именно эту часть задачи: один раз собранная страница сохраняется и затем отдаётся как почти готовый файл, что снижает время ответа сервера.

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

Второе ограничение — измеримое. Композит ускоряет только один параметр из многих, которые оценивают скорость сайта: время ответа от сервера. Ориентироваться по общей оценке скорости сайта как по показателю эффекта от композита нельзя — часть метрик он не затрагивает вовсе. Если сайт тормозит по другим причинам, сначала стоит разобраться с ними, а уже потом включать композит; общий порядок действий разобран в материале Сайт на Битрикс тормозит или не открывается — что делать.

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

Как устроен композитный кеш: общие и персональные части страницы

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

Ключевое понятие здесь — динамичный контент. Он не совпадает с тем, что в Битрикс называют динамической информацией. Динамичный контент:

• обновляется чаще, чем динамическая информация, — не реже, чем раз в несколько минут;
• может отличаться по правам пользователя;
• должен выдавать разные данные на каждый запрос.

Новости и блоги обычно не являются динамичным контентом в контексте композита, если они не зависят от пользователя и меняются редко. А вот корзина покупателя, счётчик «до события осталось столько-то времени», счётчик «сколько минут назад» у новости или баннеры, которые показываются по очереди, — типичные примеры динамичных зон.

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

Условия работы композитного кеша

Композитный кеш включается по сайтам, а не «для всего проекта сразу». В настройках указывается список доменных имён, для которых технология должна работать. Проверка идёт по полному совпадению домена, поэтому в списке должны быть прописаны все варианты написания — и с www, и без него. Если новый домен добавлен уже после включения композита, его нужно отдельно внести в список разрешённых доменов.

Отдельного внимания требует префикс cookies. В настройках главного модуля есть поле для имени префикса cookies. При использовании композитного кеша важно, чтобы префикс был настроен корректно, так как технология опирается на работу с cookies. Если префикс изменён, композит может работать некорректно.

Ещё один рычаг — параметры URL. По умолчанию разные адреса с разными GET-параметрами считаются разными страницами, и под каждый создаётся свой экземпляр кеша. Это увеличивает объём хранилища. Поле «Игнорировать следующие параметры URL» позволяет перечислить параметры, которые не должны влиять на кеш: например, метки систем веб-аналитики. Тогда для страницы создаётся единый кеш, который открывается по адресам с этими параметрами, а аналитика продолжает корректно работать.

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

Автокомпозит или ручной композит: как выбрать режим

В настройках технологии есть два способа работы, и выбор между ними — одна из главных развилок проекта.

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

Ручной композит требует, чтобы разработчик сам настроил компоненты и разметил динамические зоны. Зато здесь доступны глобальные настройки «голосования» компонентов и более гибкий выбор того, что показывать в динамической зоне до загрузки актуальных данных. Каждую новую страницу нужно настраивать отдельно. Для сложных сайтов с кастомизированными компонентами ручной способ предпочтительнее: автоматика может не учесть особенности конкретного проекта.

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

Важное ограничение: автокомпозит недоступен в облачном Битрикс24. Перед включением любого из режимов нужно очистить кеш компонентов. И ещё: активизация одного режима делает неактивной кнопку включения другого, поэтому для смены режима сначала выключают работающий.

Режим перезаписи кеша и хранение

Отдельная настройка — режим перезаписи кеша. Доступны три варианта:

• стандартный режим — кеш обновляется сразу;
• стандартный режим с задержкой перезаписи — обновление растягивается по времени, что снижает нагрузку на систему;
• режим без фонового запроса (HTML-кеширование) — подходит для страниц с большой посещаемостью, например лендингов и сайтов-визиток, где лишний запрос к серверу создаёт дополнительную нагрузку.

В режиме без фонового запроса (HTML-кеширование) обновление кеша происходит синхронно при запросе страницы, если истёк срок его актуальности. Порог настраивается.

Место хранения кеша выбирается отдельно: файлы на диске или memcached. Вариант с memcached доступен только при установленном расширении Apache. При хранении в файлах задаётся дисковая квота. Не рекомендуется устанавливать квоту слишком маленькой — при её исчерпании композит может перестать создавать новые кеш-файлы. Подсчёт квоты идёт инкрементально: при удалении файла размер уменьшается, при создании — увеличивается, поэтому вручную удалять файлы кеша не рекомендуется. В актуальных версиях старый кеш при достижении файлового лимита очищается автоматически.

Файл настроек технологии лежит в служебном каталоге и править его вручную не рекомендуется: при любом сохранении настроек через интерфейс ручные изменения затрутся.

Матрица кеширования: какие зоны страницы динамические

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

Матрицу стоит согласовать до включения композита: она показывает, сколько динамических зон появится на странице и не превратится ли выигрыш от кеша в поток отдельных запросов. Если динамических зон слишком много, страница будет открываться быстро, но заметно «дособираться» на глазах у посетителя.

Проверка личных цен и авторизации

Самая частая причина инцидентов с композитом — персональные данные, попавшие в общую статическую часть. Проверять это нужно целенаправленно, а не «на глаз».

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

Отдельно проверяют сценарии, где данные зависят от прав: закрытые разделы, персональные предложения, историю заказов. И отдельно — блоки, которые должны меняться на каждый запрос: баннеры, счётчики, рекомендации.

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

Учебный пример: интернет-магазин с персональными ценами

Учебный пример. Данные условные и не описывают реальный проект.

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

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

Как проверяли. Открыли страницу товара анонимно в инкогнито несколько раз подряд, убедились, что кеш создаётся и страница отдаётся быстро. Затем вошли под покупателем первой группы и сверили цену со скидкой. После этого — под покупателем второй группы и убедились, что видна именно его цена, а не цена предыдущего. Добавили товар в корзину под каждым пользователем и проверили, что корзина не «перетекает» между сессиями. Отдельно проверили счётчик акции: он должен показывать актуальное значение, а не зафиксированное в момент создания кеша. В конце прошли сценарий оформления заказа от начала до конца под двумя разными пользователями.

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

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

Как проверить результат и принять работу

Приёмка композита — это не «страница открылась», а набор проверок по сценариям. Ниже — применимый чек-лист.

• Кеш компонентов очищен перед включением режима.
• В списке доменов указаны все варианты написания, включая www и без него.
• Префикс cookies соответствует значению по умолчанию.
• Параметры URL, не влияющие на содержимое (метки аналитики), внесены в список игнорируемых.
• Матрица кеширования согласована и подписана ответственным.
• Анонимный посетитель в инкогнито видит корректную страницу после нескольких заходов.
• Авторизованный пользователь каждой группы видит свою цену и свои условия.
• Корзина не пересекается между разными пользователями и сессиями.
• Блоки, меняющиеся на каждый запрос (баннеры, счётчики), показывают актуальные данные.
• Пройдены типовые сценарии: просмотр, добавление в корзину, оформление заказа.
• Проверено поведение страниц с параметрами и постраничной навигации.
• Задана дисковая квота с запасом, ручное удаление файлов кеша не практикуется.
• Зафиксирован план возврата: как выключить композит, если обнаружится проблема.
• Определено, кто отвечает за мониторинг ошибок композита после запуска.

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

Типичные ошибки и ограничения

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

Вторая группа — визуальные артефакты. Динамическая зона сначала показывает заглушку, а потом подменяется актуальными данными, и это заметно как «моргание». Смягчить эффект помогает продуманный выбор того, что показывать до загрузки: например, нейтральный плейсхолдер вместо пустого места.

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

Отдельно стоит помнить про ограничения совместимости: для старых версий Internet Explorer композитный режим отключён, так как эти браузеры имеют ограничения на количество подключаемых стилей и часть CSS для них выводится иначе. Если аудитория проекта всё ещё пользуется такими браузерами, это учитывают заранее.

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

Какие исходные данные подготовить для оценки

Чтобы оценить объём работ по композиту, нужен не «доступ к сайту», а конкретный набор сведений. Чем полнее он собран, тем точнее оценка.

• Перечень типов страниц: главная, каталог, карточка товара, корзина, оформление заказа, личный кабинет, текстовые страницы.
• Описание того, какие данные на каждой странице зависят от пользователя: цены, скидки, персональные предложения, история заказов.
• Список блоков, которые меняются часто: баннеры, счётчики, рекомендации, блоки «недавно просмотренные».
• Сведения о доработанных компонентах: какие шаблоны и компоненты отличаются от стандартных.
• Список доменов и поддоменов, на которых работает сайт, включая варианты с www.
• Перечень GET-параметров, которые используются на сайте, и понимание, какие из них влияют на содержимое, а какие нет.
• Данные о нагрузке: примерная посещаемость, пиковые периоды, характерные страницы.
• Сведения о хранилище: доступный объём диска или наличие memcached.
• Требования к срокам актуальности данных: насколько быстро должна обновляться информация в динамических зонах.
• Ответственные: кто со стороны бизнеса подтверждает матрицу кеширования и кто принимает работу.

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

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