Покупатель кликает по ссылке на товар и пару секунд смотрит на белый экран, пока сервер собирает страницу: запускает ядро, тянет данные из базы, склеивает шаблон. На сотне посетителей это терпимо, но в час пик и на большом каталоге задержка превращается в отказы — человек не дожидается и уходит. В 1С-Битрикс с этим борется отдельная технология ускорения — композитный сайт, которая отдаёт готовую страницу почти мгновенно, ещё до запуска тяжёлой логики.
Ниже — практический разбор: как устроен композит, что выносить в динамику, как включить его так, чтобы не сломать корзину и авторизацию, и как прогревать кэш после обмена с 1С. Это выжимка из наших проектов по разработке и ускорению интернет-магазинов на 1С-Битрикс — без теории ради теории.
Коротко
- Композит делит страницу на статику (отдаётся мгновенно из кэша) и динамику (корзина, авторизация — догружается отдельным запросом).
- Главный выигрыш — резкое снижение времени до первого экрана и улучшение Core Web Vitals на главной, в каталоге и карточках.
- Перед включением нужно правильно вынести все персональные блоки в динамику, иначе посетитель увидит в кэше чужую корзину.
- После большого обмена с 1С композит сбрасывают по тегам и прогревают ключевые страницы в часы низкой нагрузки.
Что такое композитный сайт и зачем он нужен
Композитный сайт (часто говорят просто «композит») — это штатная технология ускорения в 1С-Битрикс. Её идея в том, что большая часть страницы у разных посетителей одинакова: шапка, меню, тело раздела, карточка товара, подвал. Эту общую часть нет смысла пересобирать на каждый запрос — её можно один раз сохранить как готовый HTML и отдавать мгновенно, а персональные мелочи (корзина, имя пользователя) подгружать отдельно.
Без композита каждый клик по сайту запускает полный цикл: ядро Битрикса, пролог, отработку компонентов, эпилог, сборку шаблона. Даже при включённом кэшировании компонентов на это уходит время, и на тяжёлом каталоге или скромном хостинге задержка ощутима. Композит разрывает эту зависимость: статическая страница отдаётся ещё до того, как стартует тяжёлая часть платформы.
Какую проблему решает композит
Композит закрывает несколько связанных болей магазина одновременно:
- Долгая загрузка первого экрана. Посетитель видит контент почти сразу, а не после полной сборки страницы на сервере.
- Проседание в час пик. Когда статика отдаётся из кэша, всплеск трафика не выливается в очередь тяжёлых запросов к базе.
- Слабые Core Web Vitals. Быстрая отдача статики напрямую улучшает метрику LCP — время до отрисовки основного контента.
- Отказы из-за скорости. Чем быстрее открывается страница, тем меньше людей уходит, не дождавшись загрузки.
Кому композит особенно полезен
Чем больше у сайта посещаемых страниц с объёмной статической частью, тем заметнее эффект. Композит окупается быстрее всего на магазинах с большим каталогом и высоким трафиком, на проектах с заметной долей мобильных посетителей (где медленные сети особенно «штрафуют» долгую загрузку) и на сайтах, которые в пики упираются в ресурсы хостинга. Небольшому сайту-визитке композит тоже не повредит, но драматического выигрыша там может и не быть — там обычно хватает обычного кэширования.
Как устроен композит: статика и динамика
Чтобы настраивать композит осознанно, надо держать в голове его базовую модель. Любая страница в композитном режиме мысленно делится на два слоя.
- Статическая часть. Всё, что одинаково для всех посетителей: вёрстка, меню, контент раздела, описание и фото товара, подвал. Эта часть сохраняется как готовый HTML и отдаётся мгновенно при следующем запросе.
- Динамическая часть. Всё персональное: содержимое корзины в шапке, блок авторизации, имя пользователя, его персональные цены, кнопки «купить» с учётом наличия в корзине, последние просмотренные товары. Это подгружается отдельным лёгким запросом поверх статической страницы.
Сценарий выглядит так: браузер запрашивает страницу, сервер мгновенно отдаёт сохранённый статический HTML (его видно почти сразу), а сразу за этим выполняется второй, быстрый запрос за динамикой, который «оживляет» корзину и персональные блоки. Для посетителя это выглядит как «страница открылась моментально, а корзина появилась через долю секунды».
Чем композит отличается от обычного кэширования
Частый вопрос: «У меня же включён кэш компонентов — зачем ещё композит?». Разница принципиальная, и понять её — значит понять, почему композит даёт другой порядок скорости.
При кэшировании компонентов ускоряется сборка отдельных блоков: список товаров, меню, баннеры берутся из кэша, а не считаются заново. Но сама страница всё равно собирается на каждый запрос — запускается ядро, отрабатывают пролог и эпилог, склеиваются кэши всех компонентов в единый HTML. Это быстрее, чем без кэша, но это всё ещё полный цикл работы платформы.
Композит идёт дальше: он кэширует уже собранную целиком HTML-страницу и отдаёт её до запуска тяжёлой части ядра. Грубая аналогия: кэш компонентов экономит «изготовление деталей», а композит экономит ещё и «сборку изделия из деталей». Поэтому отдача статики измеряется десятками миллисекунд, а не сотнями.
| Критерий | Кэш компонентов | Композитный сайт |
|---|---|---|
| Что кэшируется | Отдельные блоки страницы | Вся статическая HTML-страница целиком |
| Запуск ядра на запрос | Да, на каждый запрос | Нет, статика отдаётся до тяжёлого ядра |
| Скорость отдачи статики | Сотни миллисекунд | Десятки миллисекунд |
| Персональные блоки | Считаются в общем потоке | Выносятся в отдельную динамику |
| Эффект на LCP | Умеренный | Значительный |
Важно: композит не отменяет кэш компонентов, а надстраивается над ним. Динамическая часть страницы по-прежнему пользуется кэшем компонентов, поэтому грамотно настроенное кэширование — фундамент, на котором композит работает максимально эффективно.
Что выносить в динамику, а что оставить в статике
Главное проектное решение при внедрении композита — провести границу между статикой и динамикой. Ошибка здесь стоит дорого: если персональный блок останется в статике, его закэшированное значение увидят все посетители. Правило простое: в динамику выносится всё, что зависит от конкретного пользователя или быстро меняется.
| Блок | Слой | Почему |
|---|---|---|
| Шапка, логотип, меню | Статика | Одинаковы для всех посетителей |
| Контент раздела, фото и описание товара | Статика | Не зависят от пользователя, меняются редко |
| Подвал, контакты, баннеры | Статика | Общие для всех |
| Корзина в шапке (товары, сумма) | Динамика | Персональна для каждого посетителя |
| Блок авторизации, имя пользователя | Динамика | Зависит от того, кто вошёл |
| Персональные и оптовые цены | Динамика | Различаются по группе клиента |
| «Купить / в корзине» на карточке | Динамика | Зависит от состава корзины |
| Последние просмотренные, рекомендации | Динамика | Персональны или часто меняются |
Особое внимание — ценам. Если у вас B2B-магазин с разными ценами для розницы и опта, цена обязана быть динамической: иначе авторизованный оптовик может увидеть закэшированную розничную цену или наоборот. Как устроены такие цены по группам клиентов, мы разбираем в материале про обмен с 1С по CommerceML — типы цен приходят из учётной системы, а на витрине их нужно аккуратно показать нужной группе, не закэшировав «для всех».
Пошаговое включение композита
Включение композита — это не одна «галочка», а последовательность шагов, где главная работа приходится на проверку динамических зон. Общий порядок такой:
- Наведите порядок с кэшированием. Убедитесь, что у компонентов включён кэш (лучше «Авто» / управляемый кэш). Композит надстраивается над кэшем, поэтому сначала фундамент.
- Составьте карту динамических зон. Пройдитесь по шаблону и выпишите все персональные блоки: корзина, авторизация, цены, кнопки покупки, личные рекомендации. Это будущая динамика.
- Пометьте динамику в шаблоне. Оберните персональные области как динамические — чтобы композит исключил их из статического кэша и подгружал отдельно.
- Включите композит на копии. Сначала на тестовой площадке, а не на боевом сайте: так вы спокойно отловите блоки, которые забыли вынести в динамику.
- Проверьте под разными пользователями. Зайдите как гость, как розничный и как оптовый клиент. Убедитесь, что каждый видит свою корзину и свои цены, а не закэшированные чужие.
- Замерьте скорость. Сравните время до первого экрана и метрики Core Web Vitals до и после. Так вы увидите реальный эффект, а не «кажется, стало быстрее».
- Перенесите на боевой сайт. Только после чистой проверки на копии включайте композит на проде и ещё раз прогоните сценарии корзины и авторизации.
Как не сломать корзину и авторизацию
Самый частый страх перед композитом — «а вдруг сломается корзина». Страх обоснован ровно настолько, насколько небрежно проведена граница статики и динамики. Разберём типичные риски и как их закрыть.
Корзина в шапке
Корзина — персональный блок номер один. Если она попала в статику, первый посетитель «запечатает» в кэше своё содержимое, и следующие увидят его товары и сумму. Лечится однозначно: блок корзины помечается как динамический и подгружается отдельным запросом. Тогда у каждого посетителя своя корзина, а статическая страница остаётся общей.
Авторизация и имя пользователя
То же касается блока входа. Гость должен видеть «Войти», авторизованный — своё имя и кабинет. В статике это смешается. Поэтому область авторизации всегда динамическая. Заодно проверьте все места, где есть условие «для авторизованных» — скрытые цены, кнопки «оптовый заказ», персональные ссылки.
Кнопки «купить» и состояние товара
На карточке и в списке кнопка может менять вид в зависимости от того, лежит ли товар уже в корзине («Купить» против «В корзине»). Это состояние персональное, поэтому сама кнопка-действие — динамическая, а описание и фото товара спокойно остаются в статике. Граница проходит точно по линии «общее для всех / зависит от пользователя».
Хранилище композитного кэша и прогрев
Скорость композита зависит не только от того, что закэшировано, но и от того, где это хранится и насколько кэш «тёплый». Композитный HTML можно хранить по-разному, и выбор влияет на отдачу.
- Хранение в файлах. Простой вариант по умолчанию: статические страницы лежат на диске. Работает почти везде, но на медленном диске и большом числе страниц может уступать памяти.
- Хранение в памяти (in-memory). Когда композитный кэш отдаётся из быстрого хранилища в оперативной памяти, отдача статики становится ещё быстрее. Это требует настроенной инфраструктуры, но даёт лучший результат под нагрузкой.
Отдельная тема — прогрев. «Холодная» страница, которой ещё нет в кэше, собирается обычным тяжёлым способом — и первый посетитель ловит ту самую задержку, ради устранения которой композит и ставили. Чтобы этого избежать, ключевые страницы прогревают: после сброса кэша по ним проходят заранее (по расписанию или ботом-прогревом), чтобы к приходу живых посетителей статика уже лежала готовой.
Прогрев особенно важен для главной, верхних разделов каталога и популярных карточек — тех страниц, куда приходит основной трафик. Прогревать весь каталог из десятков тысяч страниц разом смысла нет; разумнее прогреть «горячую» верхушку и дать остальным страницам собраться по первому обращению.
Композит и обмен с 1С: сброс по событию
Композитный кэш не вечен — иначе посетитель видел бы вчерашние цены и остатки. Он сбрасывается по двум причинам: по истечении времени жизни (TTL) и по тегам инфоблоков при изменении данных. Когда товар правят через интерфейс, связанные страницы помечаются на пересборку автоматически — это работает «из коробки».
Сложности начинаются при массовом обмене с 1С. Обмен заливает в базу тысячи позиций пакетно, и если он идёт в обход стандартных событий, тегированный сброс может не сработать как нужно — на витрине останется устаревшая статика. Поэтому после планового обмена композит удобно дополнительно сбросить и прогреть по расписанию, в часы низкой нагрузки.
Логика здесь ровно та же, что и с фасетным индексом умного фильтра: после массовых операций кэш надо обновить и прогреть, иначе данные на витрине разойдутся с учётом. Мы подробно разбирали этот механизм в статье про умный фильтр и фасетный индекс — там та же дисциплина «обмен → перестроение → прогрев». Композит и фильтр удобно обновлять одной ночной процедурой после обмена.
Композит и Core Web Vitals
Скорость — это не только ощущение, но и измеримые метрики Core Web Vitals, которые учитывает поиск. Композит влияет на них напрямую, и полезно понимать, на какие именно.
- LCP (Largest Contentful Paint) — время до отрисовки крупнейшего элемента экрана. Композит отдаёт статику с основным контентом мгновенно, поэтому LCP улучшается заметнее всего.
- CLS (Cumulative Layout Shift) — сдвиги вёрстки при загрузке. Сам по себе композит его не чинит, но в связке с аккуратной вёрсткой (зарезервированное место под динамику) помогает не «прыгать» при подгрузке корзины.
- INP (Interaction to Next Paint) — отзывчивость на действия. Композит разгружает сервер в пики, что косвенно помогает отзывчивости, но INP больше зависит от фронтенда и скриптов.
Важно не переоценивать композит: он лечит «медленный бэкенд и долгую сборку страницы», но не чинит тяжёлый JavaScript, неоптимизированные картинки или сдвиги вёрстки. Это разные источники проблем, и Core Web Vitals улучшают комплексно. Как именно проседают LCP, CLS и INP в магазине на Битриксе и чем их лечить по отдельности — тема нашего материала про Core Web Vitals для интернет-магазина. Композит там — один из инструментов, и очень мощный, но не единственный.
Каким страницам магазина композит нужнее всего
Композит даёт максимум там, где много трафика и большая статическая часть. Разложим по типам страниц.
| Тип страницы | Эффект композита | Почему |
|---|---|---|
| Главная | Высокий | Много трафика, большая статика, мало персонального |
| Разделы каталога | Высокий | Тяжёлые в сборке, посещаются часто, статика преобладает |
| Карточка товара | Высокий | Описание и фото статичны, динамична лишь кнопка и цена |
| Посадочные и статьи | Высокий | Почти полностью статичный контент |
| Корзина | Низкий / исключают | Почти целиком персональна и динамична |
| Оформление заказа | Исключают | Полностью динамический сценарий с личными данными |
| Личный кабинет | Исключают | Все данные персональные, кэшировать нечего |
Вывод практичный: композит включают на «витринных» страницах, где статика преобладает, и исключают на «персональных» — корзине, оформлении, кабинете. Такое разделение даёт максимум скорости там, где она нужна, и не создаёт рисков там, где всё равно всё персональное.
Частые ошибки при внедрении композита
Большинство проблем с композитом повторяются из проекта в проект. Зная их заранее, вы сэкономите дни отладки.
- Персональный блок остался в статике. Самая дорогая ошибка: корзина или цена попадают в общий кэш, и посетители видят чужие данные. Лечится полной картой динамических зон и проверкой под разными ролями.
- Включили композит без кэша компонентов. Композит надстраивается над кэшем; без него динамическая часть всё равно тормозит. Сначала фундамент — потом композит.
- Забыли про прогрев. После сброса кэша первый посетитель ловит «холодную» тяжёлую сборку. Ключевые страницы нужно прогревать.
- Композит не сбрасывается после обмена с 1С. Массовый обмен в обход событий оставляет на витрине устаревшую статику. Нужен сброс и прогрев по расписанию после обмена.
- Включили композит на оформлении заказа. Полностью персональные страницы кэшировать незачем и рискованно — их исключают из композита.
- Проверили только гостем. Под гостем всё выглядит хорошо, а проблема вылезает у авторизованного оптовика. Тестировать нужно под всеми ролями.
- Ждут от композита чуда для фронтенда. Он не чинит тяжёлый JavaScript, неоптимизированные картинки и сдвиги вёрстки — это отдельные задачи.
Чек-лист перед включением композита
Короткий список, по которому удобно свериться до того, как включить композит на боевом сайте:
- У компонентов включено кэширование (управляемый кэш / «Авто»).
- Составлена полная карта динамических зон: корзина, авторизация, цены, кнопки покупки, личные рекомендации.
- Все персональные блоки помечены как динамические в шаблоне.
- Композит сначала включён и проверен на тестовой копии.
- Сайт проверен под тремя ролями: гость, розничный, оптовый клиент.
- Замерены скорость и Core Web Vitals до и после включения.
- Настроен сброс и прогрев композита после обмена с 1С.
- Корзина, оформление заказа и личный кабинет исключены из композита.
- Ключевые страницы (главная, верхние разделы) прогреваются после сброса кэша.
Когда композита недостаточно
Композит — мощный, но не единственный инструмент скорости. Бывают ситуации, где он маскирует проблему, а не решает её, и нужен более глубокий разбор архитектуры:
- Медленная база данных. Если динамические запросы тяжёлые, первый же поход за корзиной или ценами упрётся в базу. Лечится оптимизацией запросов и индексов, а не композитом.
- Тяжёлый фронтенд. Громоздкий JavaScript, неоптимизированные картинки и шрифты тормозят даже мгновенно отданную статику. Это отдельная работа по фронтенду.
- Нехватка ресурсов хостинга. Когда серверу не хватает памяти или процессора под пиковую нагрузку, композит снимет часть давления, но узкое место останется.
- Архитектурные проблемы каталога. Неоптимальная структура инфоблоков и свойств тормозит выборки независимо от композита.
В таких случаях скорость лечат комплексно: оптимизация запросов и кэширования, работа с фронтендом, при необходимости — пересмотр инфраструктуры, и только поверх всего — композит как финальный ускоритель. Если магазин стабильно тормозит и непонятно, где узкое место, разумно начать с аудита: посмотреть смежные услуги в каталоге всех услуг B2Bsite или сразу заняться ускорением сайта на 1С-Битрикс, где композит — лишь часть набора инструментов. На уже работающем магазине ускорение нередко идёт рука об руку с технической поддержкой: композит, кэш и прогрев нужно не только включить, но и поддерживать в актуальном состоянии после каждого обмена и обновления.
Вывод
Композитный сайт в 1С-Битрикс — это не «волшебная кнопка», а аккуратное разделение страницы на статику и динамику. Статическая часть отдаётся посетителю мгновенно из кэша, а персональные блоки — корзина, авторизация, цены — догружаются отдельным быстрым запросом. В результате витрина «открывается сразу», улучшаются Core Web Vitals, а сервер легче переживает пики трафика.
Главное при внедрении — честно провести границу динамических зон, проверить сайт под всеми ролями, наладить прогрев и сброс кэша после обмена с 1С. Сделайте эти вещи как следует — и композит станет самым заметным ускорителем магазина при минимуме рисков.
