Как проверить композитный режим 1С-Битрикс: когда кеш ускоряет магазин, а когда мешает
Как принять композитный режим на 1С-Битрикс без ложного ускорения: проверить динамические зоны, персональные данные, кеш и поведение после изменений.
В этой статье
Страница стала открываться быстрее, но в шапке на мгновение видно чужой город, цена меняется после загрузки, а корзина показывает вчерашнее количество. Это не аргумент против кеширования. Это признак, что статическую часть и персональные данные разделили неверно или приняли режим только по одному замеру скорости.
Композитная технология 1С-Битрикс сохраняет общую часть страницы и отдельно обновляет динамические области. Польза появляется, когда шаблон и компоненты к этому подготовлены. Простое включение режима не исправляет медленный запрос и может сделать ошибку менее заметной.
До включения составьте карту динамики
Для каждого фрагмента страницы задайте вопрос: одинаков ли он для двух новых посетителей и остаётся ли верным после действия пользователя? Логотип и структура меню обычно статичны. Корзина, авторизация, регион, персональная цена, доступность доставки и список избранного зависят от сессии или контекста.
Фрагмент | Обычно можно кешировать | Что проверить |
|---|---|---|
Каркас и навигация | Да | Нет ли правозависимых пунктов |
Описание товара | Да, с очисткой при изменении | Версия, язык, регион |
Цена | Зависит от модели магазина | Тип цены, договор, валюта, скидка |
Остаток и срок доставки | Часто динамика или короткий кеш | Склад, регион, свежесть обмена |
Корзина и избранное | Персональная динамика | Сессия, авторизация, несколько вкладок |
Рекомендации | Зависит от персонализации | Не раскрываются ли действия другого пользователя |
Особенно осторожно работают с B2B-магазинами: цена и ассортимент могут зависеть от организации и договора. Фрагмент, общий для розничных покупателей, перестаёт быть общим после авторизации дилера.
Проверьте три состояния, а не одну главную страницу
Минимальный набор — новый анонимный сеанс, вернувшийся пользователь с корзиной и авторизованный покупатель. Для каждого открывают карточку, категорию, поиск, корзину и оформление. Проверку повторяют в двух вкладках и после смены региона или типа цены.
На первом отображении не должно быть чужого имени, города, цены или состава корзины даже на долю секунды.
После добавления товара счётчик и итог обновляются без полной очистки всего кеша.
Выход из аккаунта удаляет персональное состояние и не оставляет его в общей части.
Изменение цены или остатка появляется в согласованный срок, а не только после ручного сброса.
Ошибки динамического запроса не должны скрывать кнопку покупки или показывать правдоподобные устаревшие данные без обозначения.
Измеряйте сервер, браузер и повторный визит отдельно
Быстрый ответ кеша уменьшает работу PHP и базы, но пользовательский результат зависит также от сети, изображений, скриптов и отрисовки. Сравнивают холодный и прогретый кеш, первое и повторное открытие, а также время до появления корректных динамических данных.
Один хороший показатель на главной не доказывает ускорение каталога. Выберите типовые страницы и фиксированный набор устройств. Смотрите медиану и высокие процентили, ошибки динамических запросов, долю попаданий в кеш и нагрузку на базу. Тест проводят до и после изменения в сопоставимых условиях.
Проверьте очистку кеша по событиям
Кеш должен устаревать управляемо. Изменение товара, цены, раздела или шаблона очищает только зависимые фрагменты. Полная очистка после каждого обмена с 1С лишает технологию смысла: магазин постоянно работает на холодном кеше и создаёт пики нагрузки.
Составьте матрицу «изменение — затронутые страницы — допустимая задержка». Для изменения описания товара это карточка и, возможно, элементы списков. Для цены — карточка, категория, корзина и расчёт заказа, но правила зависят от реализации. Матрицу проверяют реальным изменением в тестовом контуре.
Симптом | Вероятное направление проверки | Неудачное быстрое решение |
|---|---|---|
Цена меняется после загрузки | Граница динамической зоны и источник цены | Кешировать персональную цену дольше |
Кеш почти всегда холодный | События очистки и частота импорта | Увеличить срок без анализа |
Корзина показывает старое число | Сессия и обновление динамического блока | Очищать весь кеш сайта |
Периодически видны чужие данные | Персонализация попала в общую часть | Скрыть блок скриптом после показа |
Главная быстрая, оформление медленное | Некешируемые запросы и интеграции | Считать проект ускоренным |
Когда остановить включение
Режим не отправляют в боевую среду, если обнаружено смешение персональных данных, непредсказуемая очистка или зависимость покупки от успешной загрузки второстепенного динамического блока. Сначала исправляют компоненты и повторяют сценарии. Отключение проблемной страницы из режима допустимо как временная граница, если она зафиксирована и измерена.
Официальная документация 1С-Битрикс отдельно требует подготовить компоненты к технологии и предусматривает проверку работы и отладку. Это важно: переключатель в административном разделе — финальный шаг настройки, а не автоматическая сертификация шаблона.
Критерии приёмки
Ни один персональный фрагмент не появляется у другого пользователя.
Карточка, категория, корзина и оформление сохраняют корректность при холодном и прогретом кеше.
Изменения каталога очищают ожидаемые зависимости в заданный срок.
Динамические ошибки наблюдаемы и имеют безопасное поведение для покупки.
Измерения показывают улучшение выбранных страниц без роста ошибок и задержки критичной динамики.
После обновления шаблона или компонента есть короткий повторяемый регрессионный набор.
Композитный режим полезен не потому, что рядом с сайтом появился знак скорости. Его ценность — в предсказуемом разделении общей и динамической работы. Если команда умеет показать границы кеша, правила очистки и результаты сценариев, ускорение можно поддерживать после следующих обновлений, а не только в день включения.
The page loads faster, but for a moment you see a stranger's city in the header, the price changes after loading, and the cart shows yesterday's quantity. This is not an argument against caching. It is a sign that the static part and personal data were not separated correctly or the mode was enabled based on a single speed measurement.
The composite technology in 1C-Bitrix saves the common part of the page and updates dynamic areas separately. The benefit appears only when the template and components are prepared for this. Simply enabling the mode does not fix a slow request and may make errors less noticeable.
Before enabling, create a map of dynamic elements
For each page fragment, ask: Is it identical for two new visitors, and does it remain valid after a user action? The logo and menu structure are usually static. The cart, authorization, region, personalized price, delivery availability, and favorites list depend on the session or context.
Fragment | Usually, caching is possible | What to check |
|---|---|---|
Structure and navigation | Yes | Are there right-dependent items? |
Product description | Yes, with clearing on change | Version, language, region |
Price | Depends on the store model | Price type, contract, currency, discount |
Stock and delivery time | Often dynamic or short cache | Warehouse, region, exchange freshness |
Cart and favorites | Personal dynamics | Session, authorization, multiple tabs |
Recommendations | Depends on personalization | Do not reveal another user's actions |
B2B stores require special care: prices and assortments may depend on the organization and contract. A fragment shared by retail shoppers ceases to be shared after a dealer is authorized.
Check three states, not just the main page
The minimum set includes a new anonymous session, a returning user with a cart, and an authorized buyer. For each, open the product card, category, search, cart, and checkout. Repeat the check in two tabs and after changing the region or price type.
On the initial render, no foreign name, city, price, or cart contents should appear, even for a fraction of a second.
After adding a product, the counter and total update without fully clearing the entire cache.
Logging out removes personal state and leaves nothing in the shared section.
Price or stock changes appear within the agreed timeframe, not only after a manual reset.
Dynamic request errors must not hide the purchase button or display plausible outdated data without indication.
Measure server, browser, and repeat visits separately
A fast cache response reduces PHP and database work, but the user experience also depends on the network, images, scripts, and rendering. Compare cold and warmed caches, first and repeat visits, and the time until correct dynamic data appears.
One good metric on the main page does not prove catalog acceleration. Select typical pages and a fixed set of devices. Monitor the median and high percentiles, errors in dynamic requests, cache hit rate, and database load. Run the test before and after changes under comparable conditions.
Check cache invalidation by events
Cache must expire in a controlled manner. Changes to a product, price, section, or template should invalidate only dependent fragments. Full cache invalidation after every exchange with 1C renders the technology meaningless: the store constantly runs on a cold cache and creates load spikes.
Create a matrix of "change — affected pages — acceptable latency". For a product description change, this is the product card and possibly list items. For a price change, it is the card, category, cart, and checkout, though rules depend on the implementation. Verify the matrix with a real change in the staging environment.
Symptom | Likely direction of investigation | Failed quick fix |
|---|---|---|
Price changes after loading | Boundary of the dynamic zone and price source | Caching personal prices for too long |
Cache is almost always cold | Flush events and import frequency | Extend the duration without analysis |
The cart displays an outdated number | Session and dynamic block refresh | Clear the entire site cache |
Other users' data occasionally becomes visible | Personalization ended up in the shared section | Hide the block via script after it renders |
The homepage loads quickly, but checkout is slow | Non-cacheable requests and integrations | Treat the project as accelerated |
When to stop enabling
Do not enable the mode in production if personal data mixing, unpredictable cleanup, or purchase dependency on the successful loading of a secondary dynamic block is detected. First, fix the components and rerun the scenarios. Disabling the problematic page from the mode is permissible as a temporary boundary if it is documented and measured.
Official 1C-Bitrix documentation separately requires preparing components for the technology and includes checking functionality and debugging. This is important: the switch in the administrative section is the final configuration step, not an automatic template certification.
Acceptance criteria
No personal fragment appears to another user.
The product card, category, cart, and checkout maintain correctness with both cold and warmed cache.
Catalog changes clear expected dependencies within the specified timeframe.
Dynamic errors are observable and exhibit safe behavior for purchasing.
Measurements show improvement in selected pages without an increase in errors or latency in critical dynamics.
After updating a template or component, there is a short, repeatable regression test suite.
The composite mode is useful not because a speed sign appeared next to the site. Its value lies in the predictable separation of general and dynamic work. If the team can demonstrate cache boundaries, cleanup rules, and scenario results, the speedup can be maintained after subsequent updates, not just on the day of enabling.
Обсуждение 0
Делись опытом и задавай вопросы. Комментарии без ссылок появляются после проверки редактором.
Пока никто не написал. Начни обсуждение.