УслугиАрхитектура данныхКейсыЭкспертизаКонтакты Обсудить проект
1С-Битрикс

Композитный режим Битрикс: как ускорить сайт без переписывания

Команда Stormcorp · 12.06.2026 · 6 мин
Скорость сайта часто начинают чинить слишком радикально: обсуждают переезд на другой фреймворк, полную переработку каталога, замену шаблонов, переписывание компонентов. Иногда это действительно нужно. Но в проектах на 1С-Битрикс есть инструмент, который позволяет получить заметный прирост скорости без полной перестройки сайта — композитный режим.

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

В чём идея композитного режима

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

Композитный режим работает иначе. Он разделяет страницу на две части.

Статическая часть — шапка, меню, основной контент, блоки страницы, которые одинаковы для большинства посетителей.

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

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

Когда композит особенно полезен

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

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

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

Кейс: B2B-интернет-магазин с большим каталогом

В одном из наших проектов к нам обратился B2B-интернет-магазин, работающий на 1С-Битрикс. Компания продаёт товары для корпоративных клиентов: каталог, личный кабинет, интеграция с 1С, разные типы цен, быстрый заказ и повторные закупки.

Название клиента мы не раскрываем, но ситуация типичная для многих B2B-проектов на Битрикс.

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

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

Что мы нашли на аудите

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

На страницах каталога одновременно работали:

  • фильтр;

  • список товаров;

  • блок авторизации;

  • мини-корзина;

  • меню разделов;

  • блоки рекомендаций;

  • служебные скрипты интеграции.

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

Это как раз подходящий сценарий для композитного режима.

Что мы сделали

Мы не стали переписывать сайт с нуля. Вместо этого пошли поэтапно.

Сначала включили композитный режим на тестовой среде и проверили, какие страницы корректно попадают в кеш.

Затем выделили динамические зоны: корзину, блок авторизации, элементы личного кабинета и части интерфейса, которые зависят от конкретного пользователя.

После этого проверили шаблоны компонентов. Некоторые блоки мешали нормальному кешированию, потому что в них смешивались статический контент и персональные данные. Мы аккуратно разделили эту логику.

Отдельно проверили AJAX-запросы, работу фильтра, добавление товара в корзину и отображение персональных данных после авторизации.

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

Что изменилось после внедрения

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

Для клиента это было важно по двум причинам.

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

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

Где композит может навредить

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

Например:

  • в шапке может некорректно отображаться имя пользователя;

  • корзина может показывать устаревшее количество товаров;

  • персональные цены могут попасть туда, где их не должно быть;

  • фильтр или избранное могут работать нестабильно;

  • часть динамических блоков может кешироваться как статическая.

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

Композитный режим — это не замена оптимизации

Композит помогает ускорить сайт, но не отменяет нормальную инженерную работу.

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

Поэтому мы рассматриваем композитный режим как один из этапов оптимизации, а не как единственное решение.

Обычно мы идём так:

  1. Проверяем текущую скорость и нагрузку.

  2. Находим самые тяжёлые типы страниц.

  3. Оцениваем, подходит ли им композитный режим.

  4. Настраиваем статические и динамические зоны.

  5. Тестируем сценарии пользователей.

  6. После внедрения смотрим, что ещё мешает скорости.

Когда стоит задуматься о настройке композита

Композитный режим стоит рассмотреть, если сайт на 1С-Битрикс стал медленно открываться, но при этом нет задачи срочно менять всю платформу.

Особенно если у вас:

  • большой каталог товаров;

  • много повторяющихся страниц;

  • высокая доля новых или неавторизованных пользователей;

  • растущая нагрузка на сервер;

  • дорогая или сложная интеграция с 1С;

  • нет возможности быстро переписать проект.

В таких случаях грамотная настройка композита может стать быстрым и безопасным шагом к ускорению сайта.

Как мы работаем с такими задачами

Мы проектируем, разрабатываем и поддерживаем цифровые продукты на 1С-Битрикс, Битрикс24 и в мобильной разработке. В задачах оптимизации не начинаем с радикальных решений, если можно сначала получить эффект инженерными настройками.

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

Иногда сайту действительно нужен рефакторинг. Но часто первый ощутимый результат можно получить без переписывания — если правильно использовать возможности самой платформы.

Нужна помощь с проектом?

Бесплатный аудит и смета без обязательств.

Обсудить проект →