Композитный режим «1С‑Битрикс»: как устроено кеширование динамики и когда его включать

Зачем вообще «композит» если есть обычный кеш страницы

Классический full‑page кеш хорош для полностью статичной выдачи, но ломается на персонализированном приветствии, корзине и счётчиках. Композитный сайт в терминологии платформы отделяет «оболочку» и неизменяемые блоки от фрагментов, где ядро обязано пересобрать данные при каждом запросе.

Ключевая механика

• Шаблон и повторно используемые компоненты складываются в слой быстрого ответа после первого прогона.
• Изменение конкретного инфоблока или SKU запускает инвалидацию только зависимых областей карты ключей.
• Сжатие ответов (gzip/br) включают на стороне веб‑сервера — платформа задаёт содержание, CDN и nginx решают формат транспортного сжатия.

Первые визиты и прогрев

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

Не панацея перед базовой диетой страницы

Технология не заменит тяжёлые JPG, синхронные внешние скрипты и блокирующие шрифты. Пока главная строка браузера тянет мегабайты медиа, выигрыш от композита останется малозаметен.

1. Измерили TTFB и вес ресурсов в Lighthouse / WebPageTest.
2. Почистили изображения, подключили CDN для статических ассетов.
3. Проверили корректность работы авторизованной зоны (не утек ли кеш частного кабинета).
4. Включили композит через админ‑панель и контролируемый прогрев SLA.

Внедрение с разработчиком

Инструмент требует согласованной разметки компонентов и запрета кешировать чувствительные данные. Любой кастомный AJAX должен понимать, какие области инвалидации он дергает, иначе посетитель увидит устаревшую акцию после смены цены.

Ставьте задачу не как «повесить галочку», а как связку наблюдений производительности, регламента деплоя и тестового чек‑листа.