Композитный сайт Битрикс: что это и стоит ли включать

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

Что такое композитный режим и как он устроен

В обычном режиме Битрикс на каждый запрос поднимает ядро, компоненты, лезет в базу и в кэш, собирает страницу и отдаёт готовый HTML. Даже с включённым кэшированием компонентов PHP всё равно стартует, ядро грузится, и это добавляет 150-400 мс к TTFB даже на быстром хостинге.

Композит работает иначе. При первом обращении анонимного посетителя страница собирается как обычно, но результат сохраняется целиком в файл в /bitrix/html_pages/ вместе с картой динамических зон. Все следующие запросы от анонимных посетителей .htaccess перенаправляет напрямую на статический файл, минуя PHP вообще - веб-сервер отдаёт готовый HTML так, будто это обычная статика.

Куски страницы, зависящие от пользователя - шапка с «Войти» или ссылкой в личный кабинет, число товаров в корзине, блок персональных рекомендаций - оборачиваются функциями BeginNote/EndNote или помечаются как COMPOSITE_FRAME_MODE у компонента. После отдачи статики они подгружаются одним AJAX-запросом к bitrix_include_areas.php. Посетитель мгновенно видит статичный каркас страницы, а через 50-150 мс поверх подрисовывается динамика.

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

Как включить композитный режим: пошагово

Модуль называется «Композитный сайт» (composite.site). Путь стандартный: Настройки → Настройки продукта → Автоматическая оптимизация сайта → «Ускорение сайта». Мастер сам прогоняет проверки перед включением:

ul:mod_rewrite доступен и .htaccess можно перезаписывать;|PHP работает как модуль или через FastCGI, а не как CGI - иначе .htaccess-редиректы на статику не сработают корректно;|MySQL и опкод-кэш настроены штатно;|для хранения кэша можно использовать диск, memcache или redis - на VPS обычно оставляю диск, на нагруженных проектах переношу на redis.

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

Проверяю результат через заголовок ответа: curl ‑I по адресу страницы должен вернуть X‑Bitrix-Composite: Yes. Если заголовка нет - значит страница до сих пор рендерится через PHP и кэш не сработал.

curl -I https://example.ru/catalog/ | grep -i bitrix-composite

На чистом сайте на актуальной версии ядра включение занимает 20-30 минут. Но если шаблону лет пять и в нём есть прямые обращения к $_SESSION или $USER внутри верстки компонента, а не через гибридный режим, тестирование и правки растягиваются на день-два - именно столько ушло на один интернет-магазин с самописным шаблоном каталога.

Что реально ускоряется - цифры с практики

На VPS среднего уровня с MySQL и без опкод-кэша TTFB обычной страницы каталога держался в районе 600-900 мс. После включения композита для анонимного трафика - 40-90 мс, потому что PHP вообще не стартует, отдаётся готовый файл. На одном каталоге в 15 тысяч товаров это подняло мобильный балл PageSpeed с 52 до 78 без единой правки фронтенда - только за счёт TTFB и Server Response Time.

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

Где композит ломается на практике

Формы обратной связи и заказа

Если форма отправляется классическим POST-запросом на тот же URL, а после обработки компонент делает редирект на тот же адрес методом GET, этот адрес должен быть исключён из статического кэша - иначе пользователь после отправки заявки видит старую закэшированную страницу без сообщения «Заявка отправлена». У большинства стандартных компонентов Битрикс это уже учтено, но у кастомных форм с обработчиком на отдельном php-файле - далеко не всегда.

Виджеты оплаты и доставки

Калькулятор доставки СДЭК, виджет эквайринга T‑Bank или блок с остатками на складе - если такие блоки не завёрнуты в динамическую зону, они попадают в статический кэш с теми цифрами, что были на момент генерации страницы, и показываются всем анонимным посетителям, пока кэш не очистится. На одном проекте я сутки разбирался с жалобами «у вас на сайте написано другое время доставки» - оказалось, виджет СДЭК рендерился обычным include без пометки COMPOSITE_FRAME_MODE.

Персонализация и сплит-тесты

Если на сайте гоняются A/B‑тесты через cookie для анонимных посетителей, композит с ними конфликтует напрямую: тест либо не срабатывает вовсе, либо срабатывает один раз - в момент генерации статической версии страницы, а дальше всем показывается один и тот же вариант.

Страницы с большим числом URL-вариаций

Каждая уникальная комбинация GET-параметров - фильтр каталога, сортировка, UTM-метка - создаёт свой файл в html_pages. На каталоге с активными фильтрами это быстро разрастается в десятки тысяч файлов, растёт занимаемое место на диске, а сброс кэша при обновлении цен занимает заметно больше времени.

Скрипты сторонней вёрстки

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

Если каталог завязан на CRM или 1С и цены с остатками обновляются точечными доработками, обычно проще один раз аккуратно вынести такие блоки в динамические зоны, чем городить расписание сброса кэша. Такие доработки я беру в отдельные проекты - по времени это обычно несколько часов на один проблемный компонент.

Композит против других способов ускорения

table:Способ|Что ускоряет|Кому помогает|Сложность внедрения##Композитный режим|TTFB и первую отдачу HTML|Анонимным посетителям и поисковым ботам|Средняя, нужна ревизия шаблона##Управляемый кэш компонентов|Время генерации страницы на сервере (запросы к БД)|Всем, включая авторизованных|Низкая, но нужна аккуратная настройка тегов кэша##CDN для статики (JS/CSS/картинки)|Загрузку и отрисовку тяжёлых ресурсов|Всем посетителям|Низкая##Переезд на headless-фронт|Всё сразу, но фактически с нуля|Всем|Высокая, по сути новая разработка

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

Когда включать не стоит

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

На шаред-хостинге без возможности перезаписи .htaccess или с PHP в режиме CGI композит физически не заработает - мастер настройки покажет это на первом же шаге проверки. И если сайт целиком на самописном шаблоне без единой пометки динамических зон, а времени на полноценное тестирование нет, риск показать часть анонимных посетителей устаревшую форму или цену перевешивает выигрыш в скорости - особенно если суточный трафик исчисляется сотнями, а не тысячами визитов.

Частые вопросы

Композит подходит для одностраничников и лендингов на Битрикс?

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

Композитный режим совместим с обменом данными с 1С?

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

Нужно ли что-то переписывать в коде на стандартном шаблоне Битрикс?

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

Как часто нужно очищать кэш композита после изменения цен?

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