Композитный сайт в 1С‑Битрикс задуман как практичный способ ускорить отдачу страниц: сервер один раз формирует HTML‑страницу, сохраняет ее, а затем отдаёт как статический результат, подгружая «динамику» (корзину, авторизацию и т.п.) отдельными фрагментами. В учебных примерах это выглядит почти «включил — и полетело». На боевом проекте композит часто называют «неработающим», потому что он либо не включается, либо даёт минимальный эффект, либо приводит к странным «залипаниям» данных.
Ниже — разбор причин, почему так происходит, и последовательность настройки, которую я использую на проектах.
Когда считать, что композит не работает ?
Для начала нужно зафиксировать критерий «работает/не работает». На практике встречаются три сценария.
- Композитный кеш не создаётся и не используется — страница каждый раз собирается PHP.
- Композит формально включён, но метрики (TTFB, LCP) почти не улучшаются.
- Ускорение есть, но появляются ошибки отображения динамических данных (корзина, статус пользователя, персональные цены).
Чтобы перестать гадать, советую поставить расширение для Chrome - "Composite Notifier". Оно показывает, отдаётся ли текущая страница в композитном режиме, и помогает быстро поймать момент, когда композит «срывается» из‑за правок в шаблоне, подключения сторонних скриптов или появления новых вводных.
Как устроен композитный режим в 1С‑Битрикс
В основе композита — разделение страницы на статическую и динамическую части. Статическая часть (каркас) кешируется и может отдаваться очень быстро. Динамические области отмечаются отдельно и подгружаются после выдачи каркаса.
Отсюда важное следствие: композит лучше всего работает там, где страница для гостя максимально одинакова, а объём персонализации минимален и локализован в нескольких блоках.
Так почему же композит может не работать или даже ломать страницу?
Сессия и cookie у гостя
Самая частая причина — запуск сессии на каждой странице, даже для неавторизованного пользователя. Это может происходить неочевидно: достаточно кода, который обращается к $_SESSION, или логики, которая устанавливает/читает cookie и меняет ответ сервера. В результате страница перестаёт быть одинаковой для всех гостей, а композитный каркас либо не создаётся, либо не переиспользуется.Наиболее типичные места, где это всплывает: шапка сайта (город, телефон, персональные приветствия), блок «недавно смотрели», «умные» рекомендации, интеграции аналитики/коллтрекинга, которые модифицируют контент.
Слишком много динамических областей
Composite Notifier может светиться зеленым, но ускорения не будет, если вы сделали динамическим слишком большой кусок страницы. Тогда статический каркас становится формальным контейнером, а значимая часть контента подгружается поздно. Это часто ухудшает LCP и субъективное восприятие скорости, даже если TTFB слегка улучшается.Практически полезный ориентир: динамикой стоит оставлять только то, что действительно персонально и должно обновляться независимо от каркаса (мини‑корзина, блок авторизации). Крупные блоки контента лучше по возможности держать в статике и решать персонализацию другими методами кеширования.
Отключенный или некорректный кеш компонентов
Иногда композит «не держится» из‑за того, что ключевые компоненты работают без кеша (CACHE_TYPE = N) или кеш настроен непоследовательно. Ещё хуже, когда шаблон компонента выводит «случайные» значения (временные метки, генерацию уникальных идентификаторов без необходимости) — каркас перестаёт быть детерминированным, и композитный файл постоянно инвалидируется.Если композит включили, а страница всё равно пересобирается, проверка кеширования компонентов — один из первых шагов.
Серверное окружение и файловая часть
Композитный кеш — это не «магия в вакууме»: ему нужны корректные права на запись, стабильное хранение файлов и предсказуемое поведение окружения. Проблемы возникают, когда кеш‑директории чистятся внешними задачами, на файловой системе нестабильные задержки (например, неудачно настроенный сетевой storage), или когда несколько веб‑узлов работают каждый со своим набором кеш‑файлов без синхронизации.В таких условиях композит может работать «через раз»: один запрос быстрый, другой снова заставляет PHP генерировать страницу.
CDN, прокси и балансировщики
Если перед сайтом стоит CDN или обратный прокси, он может вмешиваться в кеширование: где‑то закешировать не то, где‑то, наоборот, постоянно пробивать запросы. На балансировке часто проявляется другая проблема: пользователь попадает то на узел с прогретым композитом, то на узел без него.
Поэтому при диагностике важно проверять стабильность результата на серии повторных запросов и понимать, не меняется ли маршрут до сервера.
Как настроить композит так, чтобы он давал эффект
1) Начать с «чистого гостя» и воспроизводимого теста
Я всегда начинаю с простого: открываю страницу в инкогнито, без авторизации, без параметров и повторяю обновление несколько раз. Параллельно смотрю статус в Composite Notifier. Задача первого этапа — добиться стабильного композитного режима именно для гостя. Если он не работает здесь, дальнейшая настройка динамики и «тонкие оптимизации» смысла не имеют.
2) Убрать причины, которые запускают сессию и делают ответ непредсказуемым
На практике это самый «дорогой» по времени пункт, но именно он чаще всего решает проблему. Нужно последовательно выяснить, что меняет контент для гостя: шаблон, компоненты, события, сторонние скрипты. Иногда достаточно перенести кусок логики в динамическую область, иногда — отказаться от серверной персонализации на уровне каркаса.
3) Свести динамические области к необходимому минимуму
Чем больше динамики, тем меньше композит даёт выигрыша. Хорошая настройка — это когда пользователь быстро получает полноценный контент страницы, а динамика дополняет его точечно, не перетягивая на себя основную часть первого экрана.
4) Привести кеширование компонентов к единой логике
Дальше имеет смысл пройтись по критичным для производительности страницам (главная, каталог, карточка товара) и проверить, что компоненты используют кеш там, где это допустимо, и что вывод не содержит случайных или зависящих от запроса данных в статической части.
Если на проекте сложные условия (гео‑цены, разные типы цен, скидки по группам), важно отдельно продумать, какие параметры должны участвовать в «вариативности» кеша. Иначе вы получите либо «залипание» данных, либо постоянные промахи кеша.
5) Проверить инфраструктуру: один сервер, кластер, CDN
После того как логика на уровне приложения приведена в порядок, композит нужно «дожать» на инфраструктуре: убедиться, что кеш создаётся и читается, что нет конфликта с прокси/CDN, и что на нескольких узлах поведение одинаковое.
Как корректно проверить результат
Корректная проверка — это не один замер «до/после», а серия повторов в одинаковых условиях. Я обычно смотрю как минимум две вещи: стабильность работы композита (по Composite Notifier) и изменение метрик загрузки (TTFB/LCP) на повторных заходах. Если композит включился, но LCP вырос, это сигнал, что динамические области стали слишком тяжёлыми или критичный контент переехал в подгрузку.
Заключение
В большинстве случаев композитный режим в 1С‑Битрикс «не работает» из‑за вполне конкретных причин: сессия у гостя, избыточная динамика, отключенный кеш компонентов или конфликт с инфраструктурой (CDN/балансировка/файловое хранение). Рабочая стратегия — начинать с воспроизводимого теста для гостя, контролировать статус через Composite Notifier, затем последовательно устранять источники недетерминированности и только потом оптимизировать границы динамических областей.